5

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...

Luis Gouveia
  • 8,334
  • 9
  • 46
  • 68
  • how are your views/controllers heavy? Are you doing a lot of operations? Accessing data in the controllers? Sorting/Filtering on View side??? – CSharper Mar 10 '14 at 13:14
  • http://stackoverflow.com/questions/4565681/where-does-the-business-logic-layer-fit-in-to-an-mvc-application?rq=1 http://stackoverflow.com/questions/18563229/mvc-where-to-put-business-logic?rq=1 – user1010863 Mar 10 '14 at 13:14
  • @user1010863 I attempted to basiacally say what that answer said but , I couldn't have said that answer any better myself – CSharper Mar 10 '14 at 13:17

5 Answers5

3

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.

Community
  • 1
  • 1
jdehlin
  • 10,909
  • 3
  • 22
  • 33
  • 1
    I am definitely in favor of using view models for many reasons. Generally a view will need more than provided by a single domain model. A view model allows you to provide all of the necessary data for the view without throwing things in the ViewBag. The view model also gives you a place to put logic and expressions that would otherwise have been done in the controller action or directly in the view. – jdehlin Mar 10 '14 at 14:29
  • Hi jdehlin, thanks for you answer and post blog. I would like to hear your opinion about Sebin's post. Do you agree with him? Isn't it a bad practice to have both controllers and third party classes sending Models/ViewModels to the View? My controllers are sending the respective Model to the view, but I hesitate on creating third party classes that will send ViewModels to the view as well. I would appreciate your expertise on the MVC problematic. I've read that some people are treating MVC like if it was MVVC in fact, and I think that might be the case. – Luis Gouveia Mar 10 '14 at 14:44
  • 1
    It's not that you send both a model and a view model. Your model, if needed, can be added to the view model. Or you can make your view model have similar properties to your model and map one to the other using something like AutoMapper. Or you can have your view model inherit from domain model and override/expand on it. This flexibility is the benefit of a view model. You design it for the view on a case by case basis, rather than trying to mold your domain models to fit your views. I think this is what Sebin means by emit view models. – jdehlin Mar 10 '14 at 15:19
  • Thank you jdehlin, I will definitely learn more about the ViewModel usage, but I can assure you that many developers consider it to be a bad usage of the MVC model, because it looks more like the MVVC pattern. Take a look at the last answer (30 vote-ups): http://stackoverflow.com/questions/16548376/asp-net-mvc-how-exactly-to-use-view-models – Luis Gouveia Mar 10 '14 at 15:25
  • 1
    I agree with most of what Chris Pratt has to say in the linked response. I would disagree that persistence belongs in the domain model, though. I would argue that persistence belongs in the application layer. View models aren't just to represent domain models in different state (although than can be for that). For example imagine we have a view which displays data from three different domain models. We can create a view model which has three properties, one for each of the domain models we need in our view. – jdehlin Mar 10 '14 at 15:48
  • 1
    There isn't really one "right" answer to this question. The best thing you can do is learn and practice the underlying principles behind why people do these things. The [SOLID](http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) principles, etc. etc. – jdehlin Mar 10 '14 at 15:50
  • I understand you, but according to him (as far as I could understand), in that case you would repeat code on each model, and that wouldn't do no harm. The idea is to create one model per view, even when you're using almost the same model for different views... In any case my biggest concern was where to put the logic. Now I see I must use repository and unit of work: http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application thanks for your time jdehlin – Luis Gouveia Mar 10 '14 at 15:54
2

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.

vidalsasoon
  • 4,365
  • 1
  • 32
  • 40
1

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.

Community
  • 1
  • 1
Kamil Będkowski
  • 1,092
  • 4
  • 16
  • 36
1

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.

Sebin Eapen George
  • 205
  • 1
  • 8
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

Luis Gouveia
  • 8,334
  • 9
  • 46
  • 68