Implementing application logic on model layer (MVC)

Question

I keep reading that the biggest layer in the MVC pattern should be the model. I've also heard that we should avoid putting logic on the controller layer. However, as my ASP.Net MVC 5 application is getting larger, I see that I'm getting heavy views, heavy controllers, and... extremely tiny models (they're not more than references to my SQL tables).

Yes, I admit, I could never manage to put any logic on my model.

I like the MVC pattern, and my website is working good, but I keep on thinking that I'm surely not doing things right...

Can you show me some useful links about how to write MVC code properly? Rick Anderson's (Microsoft) MVC 5 tutorial is fine, but once again, his models are indeed very tiny...

Answer 1

After some research on this issue, and taking into account some of these answers and comments, I realized that a medium sized MVC project can't rely exclusively on the 3 layered model. As the controller actions become bigger, the developer starts feeling the need of creating a 4th layer: the service layer. Like Gunnar Peipman correctly suggests in the following blog post, "Controller communicates with service layer and gets information about how access code claiming succeeded": http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx

Answer 2

In my applications I put as much logic as possible in the domain models. On top of that there is an application layer which interacts with the database and domain models to perform application specific operations. The controller actions have as little code as possible and just call methods in the application layer.

In addition I usually have a view model for each view. Any logic that you have making your views "heavy" would go there.

One of the main reasons I try to put as much logic as possible in the domain models is to make unit testing easier. Logic in the application layer usually involves the database, which you will need to mock in order to test. Moving logic to the domain models makes testing easier and makes you code more reusable.

This is a pretty complex issue. I have an in depth blog post on the question if you're interested.

This answer is also pretty close to what I would suggest.

Answer 3

You should Create Some Classes that purely doing business logic and emit ViewModels for MVC view. Controller should respond to actions and the action method delegate the responsibility of getting the model to this business classes.

Answer 4

You're missing a service/business layer which should be injected in your controllers though "Dependency Injection". These services do all the heavy lifting.

Having Models without any methods or operations in them is a good thing. You're only storing this info anyway. They basically just get; set; data.

Answer 5

Use extra layer between models and controllers (for example repositories as data access layer). I strongly recommend using ViewModels-they make code much more organized.