Model View Controller Explained
According to Wikipedia’s entry on Model View Controller:
Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other.
MVC if often referred to as a design pattern and in a lot of ways it is, though it has more to do with the architecture of an application. The general definition of MVC involved three parts, the model, the view and the controller. Makes sense, huh?
The model represents the domain specific information on which an application runs. More times than not, the model use a database as the persistent storage mechanism for this information. Even through other mechanisms can be used the model is main goal is to encapsulate data access and domain specific logic.
The view is the front end representation of the application, typically a user interface, although a programmatic API could also be considered a view.
The controller processes and responds to events coming from either the view or the model. It becomes the interface between the model and view. It can be used to control navigation, business logic, and a host of other things.
I have seen a large number of different implantations of the MVC patterns and have struggled with and argued about where business and domain logic should reside and the best way to implement it. This comes to no surprise given the history of the pattern and the fact that is has been the center of many holy wars in the technological industry and academic circles.
Two sub-types that I like to use in describing two major paths the pattern has gone are referred to Model 1 and Model 2 MVC.
In Model 1 architecture, requests are made of the view and the view handles all responsibilities for the request, validation, business logic, display logic, and generating a response (including navigation). This leads to problems with duplicate code and state control in the view. It makes it harder to move or change the interfaces implementation and can lead to maintenance nightmares. Model 1 tends to couple the presentation logic with business logic. One distinction that must be made clear is that the code behind in ASP.NET applications and a Java servlet’s in Java is considered part of the view (though a servlet can be more flexible given the fact that it can be called by a number views).
In Model 2 architecture, the presentation is deliberately separate from the content. The context of the application is maintained by the controller. The controller is often used to control navigation from one view to the next. The view can be implemented to contact the model (JavaBeans) or model interaction can be brokered by the controller (Microsoft’s UIProcess, Web Client Software Factory and Apache Foundation’s Struts Actions).
In web development, I have had great success with using Model 2 that has extremely light weight, ‘dumb’, views where the controller controls navigation, maintains state (including state persistence), and brokers all communication with the model. I have also wrestled with the downside of Model 1.
