MVC (Model-View-Controller)

During a recent content audit of my website, I was quite surprised to learn that I haven't even written one meager little post about the MVC (Model-View-Controller) architecture pattern.



Originally titled Thing-Model-View-Editor and a few months later recoined as Models-Views-Controllers by its creator Trygve Reenskaug around the end of the 70's, so its hardly a new pattern, but evolved (perhaps more accurately was raped and bastardized in the opinion of some), quite a bit over the decades.

You can literally find millions of articles all over the web on the subject, a lot of which contradicts each other, often causing controversy, even though this is supposed to be a simple concept.

The main problem is that since MVC is a high-level pattern, the lower-level design part of things tend to cause all of the confusion.

Lets start with a definition.



MVC is all about the separation of concerns, typically C (controller) handles user actions, which it passes (if applicable) to M (model, application core), in turn the result of M gets passed to the appropriate V (view, UI) for output.

1. Should the Model and View be allowed to communicate with each other?
   
   Apparently quite a bit of a controversial topic, some like it, some don't like it, but before getting all dogmatic about things, think about it from a separation of concerns point of view.
   
   
   
   If the View and Model Layer is tightly coupled with one another, whenever we change something in the one it ripples up (or down, depends on your angle), not to mention reusability issues.
   
   E.g. I recently sat with an issue where a developer created an API tightly coupled with a WinForms form, it made the code very difficult to use in my MVC environment.
   
   Personally I would prefer to have these two loosely coupled.
   
   
2. Where must I put my business logic?
   
   This question is typically asked by someone trying to apply n-tier based design principles in the MVC environment.
   
   Firstly we need to understand that business logic potentially comprises of both domain logic (e.g. calculations, rules etc. - independent of application) and application logic (e.g. workflow - interaction with domain logic) .
   
   Domain logic should be placed in the model layer, while application logic lives in the controller.
   
   I normally tend to reuse my model layer in other applications, so I need it to be completely decoupled from whichever application that uses it.
   
   
3. Where must I do my validation?
   
   Validation is the responsibility of the model layer, but that said, it depends on the context in which you are implementing the MVC pattern.
   
   When using it in a web context, we generally do some additional client side validation on the View as well before handing things over to the Model layer (technologies like ASP.NET MVC will even go as far as to automatically wire up JavaScript validation for you, if setup correctly via Data Annotations).
   
   

Expect to see a lot of MVC posts in the future on this website.

I am planning to write some tutorials especially on ASP.NET MVC - which is really more of a MVVM design, adding abstraction between the Model and the View (ViewModel).

I am also planning to release my personal PHP MVC framework to the open source community as soon as I am happy with it (are we truly ever happy with our code?).