MVC Business Logic – Why Put Business Logic in the Model?

business-logicmvc

I always thought that the business logic has to be in the controller and that the controller, since it is the 'middle' part, stays static and that the model/view have to be capsuled via interfaces. That way you could change the business logic without affecting anything else, program multiple Models (one for each database/type of storage) and a dozens of views (for different platforms for example).

Now I read in this question that you should always put the business logic into the model and that the controller is deeply connected with the view.

To me, that doesn't really make sense and implies that each time I want to have the means of supporting another database/type of storage I've to rewrite my whole model including the business logic.

And if I want another view, I've to rewrite both the view and the controller.

May someone explain why that is or if I went wrong somewhere?

Best Answer

ElYusubov's answer mostly nails it, domain logic should go into the model and application logic into the controller.

Two clarifications:

  • The term business logic is rather useless here, because it is ambiguous. Business logic is an umbrella term for all logic that business-people care about, separating it from mere technicalities like how to store stuff in a database or how to render it on a screen. Both domain logic ("a valid email address looks like...") and workflows/business processes ("when a user signs up, ask for his/her email address") are considered business logic, with the former clearly belonging in the model and the latter being application logic that goes in the controller.
  • MVC is a pattern for putting stuff on a screen and allowing the user to interact with it, it does not specify storage at all. Most MVC-frameworks are full stack frameworks that go beyond mere MVC and do help you with storing your data, and because the data that should be stored are usually to be found in the model, these frameworks give you convenient ways of storing your model-data in a database, but that has nothing to do with MVC. Ideally, models should be persistence-agnostic and switching to a different type of storage should not affect model-code at all. Full fledged architectures have a persistence layer to handle this.
Related Topic