Fat model / thin controller vs. Service layer [closed]

by

All of this depends on the intention and requirements of your application.

That said, here’s my suggestion for “mid scale” (not a local restaurant, and not Twitter/Facebook) web applications.

  1. Lean Domain Modeling

    Dry POCO style objects, preferably ignorant to the MVC architecture of your web application to remain as loosely coupled from your particular implementation as possible.perhaps even class library repack-able for use in an external application, say a REST API via a WCF Web Service).

    “Model” in MVC most accurately means the model the Controller is aware of and thus the the model intended for the View.

    In smaller (often Tutorial) applications the entity models of your “Application/Domain Model Layer” are often the same instantiated objects the controller ships off to a View.

    In larger applications developers often employ the tenets of MVVM architecture and begin using separate View Model objects. The controllers often call middle-tier services that work with the unseen entities below. In this scenario, the M in MVC most accurately means the View Model.

  2. Robust Service Layer

    This does not mean obese logic, but well-written single purpose services. While coding your business logic in services outside of the model is a bit more “procedural” than it is pure “OOP”, it helps a lot with loose coupling, testing, and flexible deployment (ex. n-tier deployment).

    In my personal practice, I code services both down at the data layer, which I consider my behavioral modeling of the POCO objects (persistence mechanics, low level validation, etc.), and higher level services (business/workflow function) up closer to the MVC mechanics.

  3. Lean Controllers

    I make sure my controller is merely the coach, in that it is neither the play (services) or the player (entity model or view model), but simply decides who plays what position and what play to make. My controllers do two things:

    1. Call services that interact with the entity/domain Models

    2. Prepare a View Model for the appropriate View.

    Even authenticated/authorized controller actions are done via injected services/attributes.

EDIT 1:

Keep in mind, that this does not mean your Entity/Domain Model is or must be anemic. ORMs, repositories and factories, validation or state mechanics are welcome. It only means for applications of moderate scale, the Model in MVC represents the model meant for the controller, to hand off to your View.

Hopefully this point will calm Fowler apostles who believe the anemic data model to be an anti-pattern. At the same time, it does reflect a slightly more procedural angle than OOP where it is more pure to include behavior in the modeled classes.

There is no “ultimate truth”, but using this pattern you’ll find it easy to build, test, and deploy your applications – while maintaining a lot of re-usability and scalability.

EDIT 2:

That said, even for modestly sized applications, over architecting (that a word nerds made up?) a system is much too common. For instance, wrapping an ORM with a repository pattern, and then writing services to use the repository… all this is good for separation of concern and such, but if your project doesn’t require (and is not very likely to soon require) such things, don’t build it. There is nothing wrong with skipping the repository all together, writing thin business services (ex. query classes) against an ORM, or even having your controller talk directly to it. It all depends on scale.

EDIT 3:

I wanted to note that this explanation and advice is for the context of server-side MVC architecture like ASP.Net, not for clent-side frameworks like Knockout or Backbone.

More Related Contents:

  1. How to pass parameters to a partial view in ASP.NET MVC?
  2. Using Ajax.BeginForm with ASP.NET MVC 3 Razor
  3. Cascading drop-downs in MVC 3 Razor view
  4. Getting “A potentially dangerous Request.Path value was detected from the client (&)”
  5. ASP.NET MVC Ajax Error handling
  6. Handling session timeout in ajax calls
  7. ASP.NET MVC 3 client-side validation with parameters
  8. How do you share scripts among multiple projects in one solution?
  9. Should services always return DTOs, or can they also return domain models?
  10. ASP.NET MVC3 and Entity Framework Code first architecture
  11. MVC3 unobtrusive validation group of inputs
  12. Purpose of ActionName
  13. ASP.NET MVC 3 Razor – Adding class to EditorFor
  14. Is there any good reason to use FormCollection instead of ViewModel?
  15. How to set ViewBag properties for all Views without using a base class for Controllers?
  16. Is it possible to create a generic @helper method with Razor?
  17. pass enum to html.radiobuttonfor MVC3
  18. Best place to set CurrentCulture for multilingual ASP.NET MVC web applications
  19. Razor actionlink autogenerating ?length=7 in URL?
  20. ASP.NET MVC – Authenticate users against Active Directory, but require username and password to be inputted
  21. Should ServiceStack be the service layer in an MVC application or should it call the service layer?
  22. Is using ViewBag in MVC bad? [closed]
  23. MVC 3 file upload and model binding
  24. Does Razor syntax provide a compelling advantage in UI markup?
  25. Implementing “Remember Me” Feature in ASP.NET MVC
  26. Redirect to Action in another controller
  27. active menu item – asp.net mvc3 master page
  28. In what order are filters executed in asp.net mvc
  29. Html.DisplayFor not posting values to controller in ASP.NET MVC 3
  30. How do I create my own Scaffold Template in ASP.NET MVC 3?

Leave a Comment