MVC: Where to put business logic? [closed]
I prefer to put domain logic in the model for a couple of reasons.
The model should have no UI code in it and thus be easier to test. Whenever possible, I like to have a fully working (meaning complete test coverage) model before writing any UI code. The controller can trust that the model is doing the right thing and just deal with UI concerns.
If you put domain logic in a controller, it's not as easy to share between different apps, or even between different controllers.
I like to keep my models clean I.e. Just with properties and no business logic. I always think its good to inject dependencies into the controller and these dependencies contain the logic I perform on my models. I like to adhere to the single responsibility principle where possible and I find that models with tons of methods get bloated very quickly. There's pros and cons for both, injecting a lot of dependencies has an overhead yet allows to test in isolation and keeps classes simple and you'll end up having leaner controllers. Despite my logic not actually existing on my model as members of the class, its still business logic. I tend to not have business logic defined in the controller as mocking things like the Httpcontext are a bit of a nightmare and unnecessary.
The business logic belongs to the problem domain and everything that belongs to the problem domain goes to the model in MVC.
The controller should be responsible for passing the data from the model to the view and from the view back to the model. The controller is therefore the bridge between what the user interacts with and how the program models and stores the state of the problem. The plumbing, so to speak.
The key here is the distinction between the business logic and the plumbing logic. In my opinion, what the autogenerated Account Controller does is mostly plumbing, not really business logic. Keep in mind that the plumbing logic isn't necessarily short at all, so you don't need to impose artificial limits (like "X number of calls at most in the controller").
There seems to be some confusion around this topic. Mostly it seems that people tend to confuse the MVC pattern with N-tier architecture as an either/or situation. The reality is that the two approaches can be used together, but one is not dependent on the other and neither is required.
N-tier architecture is concerned with separating an application into multiple tiers. A simple example is where the application is split into a presentation layer, a business logic layer, and a data access layer.
MVC is a design pattern dealing with the presentation layer of an application. It is entirely possible to design an application following an MVC approach without separating business logic and data access logic from the presentation layer and thus end up with a single tier design.
The result, if you are following an MVC approach without also separating the application into tiers is that you end up with Models, Views, and Controllers that have bits of business rules and data access logic mixed in with the rest of the logic.
By definition, in an N-tier architecture, the presentation tier is only supposed to be able to communicate with the business logic layer so it should hold that any of the MVC components can only communicate with the business logic layer.
If you are building an application that does not involve presentation, and thus not a presentation layer, you should not have to concern yourself with the MVC pattern. However, you very well may still split your application into multiple tiers and thus follow an N-tier design even though there is no presentation layer involved.