Thursday, May 1, 2014

Fat model / thin controller vs. Service layer

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.

No comments:

Post a Comment