Everybody speaks about MVC - the de facto standard for building modern application. Here is a short article to the basics and history of MVC.
Short introduction to Model View Controller
MVC intention is to build applications in a modular way, where we have 3 general parts responsible for creating the output and allowing the interaction with the user:
In the context of the MVC the model has the data that is required to render things in the view. So it represents the data that are required for rendering. It also takes over the operation related to the domain.The model is used to do something and get the data.
takes over the display of the applications state. A view takes care of „rendering the pixels on the screen“ and should be as dump as possible. Typically a view class understands one or more model(s) and outputs the information of that model. ( A view is not allowed to write in the model.) So the view is aware of the model and knows how to read the data out of it – but never the model should know something about the view!
It glues together Model and View, it controls the user interaction with the model and the view. (Its a thin layer that connects models with there views)
The historic basic "smalltalks-80" classical MVC:
One of the first MVC framework was the smalltalks-80 MVC implementation in the 80s. Smalltalk is a pure objectoriented programming language, and the MVC concept was a key feature.
It was designed for Desktopapplications and the main idea is to seperate the presentation from the domainmodel.
Controller and view do not know each other. Instead the view updates itself through observing the relevant model. Therefore the models needs to implement the observer pattern. Controller handles the userinputs and delegates the useractions to methodcalls in the models.
A complete screen can be understand as a collection of widgets - each widgetelement consit of its own View and Controllerobject.
Downsides of the smalltalks 80 MVC concept:
Usage of the Observer Pattern: You dont know whats going on by reading the code.
Complex Screens get really complex because of a hierarchie of widgets with own View and Controller part. Specially if you have the requirement to know about a user action in more controllers.
Problem of handling logic that is only related to presentation => that is put into the view - so the view gets some logic which is not optimal.
This MVC concept is not really relevant for typical Webapplications!
MVP vs MVC
The smalltalk developers recognized the downsides of the classical MVC concept and introduced a simelar concept called MVP (Model View Presenter).
The role of the presenter within MVP is to interpret the events and gestures initiated by the user and provide the business logic that maps them onto the appropriate commands for manipulating the model in the intended fashion.
While it is the view’s responsibility to display model data it is the presenter that governs how the model can be manipulated and changed by the user interface. This is where the heart of an application's behaviour resides.
In many ways, a MVP presenter is equivalent to the MVC controller.
The main difference is that a presenter is directly linked to its associated view so that the two can closely collaborate in their roles of supplying the user interface for a particular model. This can be very handy at times and is one of the most obvious benefits over MVC where the application model only has an indirect link to its associated view.
However the shortcut "MVP" is not so common like "MVC" but most of the MVC frameworks you find for webapplications follows more the MVP concept.
MVC for Webapplications
The concepts above were initialy developed for desktop applications. In desktop applications you have a direct connect between UI components and the responsible controller or presenter. In webapplications you normally dont have this: The HTML for a complete screen is sended to the browser. If the user do some actions in the UI a request is send to the webserver - this request has to be interpreted and normally the complete (updated) screen needs to be sended to the browser again.
The HTML for the complete screen can be understand as a set of widgets (or subviews). For example it can contain a "mainmenu", a "newslist", a "basket" etc. The webserver always needs to generate the complete view with all its subviews.
A MVC Framework for webapplications therefore normally works this way:
- The request that is send from the browser to the webserver is send to a front controller. This front controller builds a request object and starts the processing of this request.
- That means Controller Objects are called (normally action methods in the controller that belongs the current request. This process is called "dispatching") and this controllers are responsible to return the correct response. Like normal controllers they do:
- The controller loads/modify model objects
- Pass the model to a view
- calls the view "render()" method to get the response.
- Normally the view that is returned to the browser consist of a hierarchie of subviews and/or widgets.
MVC Frameworks for webappications: