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

I'm no MVC expert, but try and concentrate on the fact that the controller should use the input from the user to direct them to the correct view.

I don't know if NerdDinner is an ideal example, but you can see Scott Hanselman et al does a little bit of data access from his EF context but pushes most of the other logic to service classes or helpers on the model.

I don't know if I agree with the 'models heavy' part, as I don't use the models as 'business objects'. If I really need a lot of 'business' logic, I will typically create that in a separate 'Domain' layer and may even have a separate Data Access layer on top of this. But for a lot of simple (see: non-enterprise) projects, this is overkill in my experience.

Answer 2

_{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 3

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.

Answer 4

In the classic Model-View-Controller MVC pattern, your Model is essentially a "headless" application, with no UI and is completely UI-agnostics. It offers an API that is the functional core of the application.

The View is the user interface, however you choose to define it (web page? elevator control panel? something else?). A given application might have 1 view or it might have many views.

The Controller (or Controllers — like Views, you might have one to many Controllers for a given application) relays and transforms events, notifications and data between View and Model so as to preclude the Model from needing to know anything that is View-specific.

The idea is to isolate the core application (the Model) from the user interface (the View). From that some things follow:

• The View is aware of and communicates with both Controller and Model (you're unlikely to try to wire up the View to another Model) and expected for the Controller to be aware of both View and Model.

• The Controller is aware of and communicates with both View and Model.

• The Model knows nothing of Controller or View.

Code that performs business logic should be in the Model, not in the Controller.

Answer 5

In simple terms, Model represents the underlying data that your application will be using. It is to be designed in a way that it can be used across different applications. For example, A model to represent News data can be used by console commands, Web service etc. It is in model where you will have ur business logic defined, independent of the view.

Controller can be thought of as glue that binds Model and View together. They deal directly with client requests and accordingly interact with views and models.

In a well designed application, you data structure and business logic will be designed in a Model, making it "heavy". While Controller will just interlink your model and view with the client requests, making it "light".

Answer 6

Model is the core of your application. It is best to think of models as of your business entities. Do you want to create a view of an invoice? Then Invoice be your model, it represents the underlying object.

Controller is just a way to handle requests from a client, retrieving the data from database (or updating them) and flushing out the responses.

Your thoughts about the application design should be model-centric, that's the important part.