Having MVC controllers light and models heavy

Question

I have heard that the controller should be kept light and models heavy.

I am somewhat confused about the best practice on what should be kept in the controller and what should be kept in the model.

In our organization, we use Entity Framework where and put the tables there.

For the controller, we use LINQ and then send the info over to the view.

Kind of confused on what code should be in the Controller and in the Model.

Answer 1

_{Disclaimer
The whole topic is a giant mess. Especially when it comes to Web MVC. For all practical purposes it is impossible to use classical MVC pattern for web, because the view should be observing model. Theoretically you could implement something like that with WebSockets, but keeping a persistent model for each user is not a realistic solution.}

Here is what you must know about MVC

The most important idea in both classical MVC and MVC-inspired patterns Separation of Concerns. It divides the application in two major layers:

• Presentation layer

  Governs the user interface. It deals with both creation of the interface and reacts to the user's manipulation of this interface. This interface might be GUI for a desktop application or HTML web page, but it also can be REST API or receiver-responder on a Mars rover. This is why a web application can implement MVC pattern in both frontend and backend.

  The mandatory parts are views and controllers, but, in context of web, fully realized views usually also use multiple templates to create the interface.

• Model layer

  This is where all the business rules and logic lives. The M in MVC is not a single entity. Instead it is a layer, which contains different structures. Some of those structures are also responsible for interaction with storage.

What are the responsibilities of controllers ?

Controllers are part of presentation layer, which deals with user input. In context of web-based implementations, you will usually have 1:1 relationship between views and controllers, where controller receives the requests from browser and, based on the content of said requests, alters the state of model layer and view.

If you are using classical MVC or Model2 MVC, then that is the extent of controllers responsibilities.

In MVP and MVVM patterns, where you have a passive view, controller-like structures are responsible for acquiring information from model layer and passing it on to the current view instance. This post might provide some additional details on the MVC-inspired patterns.

But the controller is in no way responsible for any form of business logic. If it was, it would mean, that you have a leaking abstraction, because the structures of presentation layer would be doing work, which should be in the model layer.

Usually the controllers will the be simplest structures in you application.

What about the model ?

As mentioned before, model is a layer, which encompasses all of the domain business logic and related functionality. This layer , just like presentation layer, is made up from multiple groups of structures:

• Domain Objects^[1]

  These structures are usually what people mean, when talking about "models". They are also known as model objects or business objects. This is where most of domain business logic ends up.

• Data Storage Structures

  This group would contain all of the classes, which abstract the interaction with storage (SQL databases, caching systems, noSQL, remote SOAP or REST APIs). They will usually implement some variation of data mapper or repository pattern , but you could be using some other solutions too, like unit of work. The implementation details are not so important. What is important is that they let you store data from and retrieve information into your domain objects.

• Services

  Or you could call the "components". There are high level abstractions in your model layer, which facilitate the interaction between domain objects and storage structures. The usually represent large chunks of model layer, like "recognition service", "mailers", "article management", and will provide the interface for presentation layer to interact with.

Answer 2

That's something of a religious debate. Some like as little as possible code in their controller and other as little as possible in their model. Do what feels natural to you in the project, but be consistent within it.

All else is dogma you can pick an example either way and make a case.