Model
The model represents the data or knowledge within a system. It usually comes from, but is not limited to, the data in the database and may include business logic. To my mind, it's really the information that the user wants to see on their screen.
View
The view is responsible for displaying the model on the screen. In the case of a web-app it’s presented by the browser and in the Java world, it’s commonly built using JSPs.
Controller
The controller links the user, model and view together, taking a user’s request, marrying it with the appropriate model and combining the model with the appropriate view.
The diagram that explains this usually looks something like this:
The benefits of doing this include reuse-ability, for example using the same controller to talk to both a web browser and a phone; maintainability as it’s easier to find, fix and enhance things; and testability, as you can test each component separately.
The MVC pattern was invented by Trygve Reenskaug and has been around since about 1978. Trygve Reenskaug both has his own page on Wikipedia and maintains his own web-page detailing MVC.
So far as web-apps go, there seems to be as many versions and definitions of the MVC as there are grains of sand on a beach, with various debates about what constitutes a model and a view. For example, in a web app does the view include the HTML or is it just the CSS? Hopefully, I’m not being contentious when I say that webapps generally employ a variation of MVC known as the Front Controller Pattern. In this pattern, there is usually a servlet that receives requests from a browser. This servlet examines the request and then delegates it to another object which acts as a sub-controller tying together the view and model for that particular request.
Early implementations of the Front Controller often used what is known as the JSP Front Strategy, whereby each JSP for a particular request acted as the sub-controller. In using this strategy you are often faced with the task of writing a whole bunch of custom tag libraries for inclusion in each page. These are responsible for both marshaling the model and determining how it was presented on the view. From experience this leads to a breakdown in the separation of concerns with bits of controller, model and view all mixed together in one place and is usually demonstrated by JSPs within JSPs, containing custom tags for presentation logic, mixed with other custom tags for data access and all merged with Java Scriptlets, HTML, Javascript and a general air of developer confusion. When the separation of concerns breaks down, MVC breaks down and several anti-pattern rear their ugly heads including Functional Decomposition, the Monster Object and the Big Ball of Mud. Sun (now Oracle) in their J2EE Core Patterns do not recommend using the JSP Front Strategy. From experience this is something I definitely agree with... The following diagram demonstrates the pitfalls of the JSP Front Strategy:
More recent implementations, steering well clear of the JSP Front Strategy, will delegate to a pure Java sub-controller, leaving the JSP solely responsible for sorting out the presentation. The sub-controller’s responsibility is to grab the data from the model and poke it into the JSP for rendering. This approach has been hugely successful having been adopted by many of the web application frameworks such as Struts, which uses Action classes, and Spring MVC which uses its @Controller annotation in version 3 and handler classes in version 2.x.
There must be some pitfalls in using this technique, but no serious ones, such as the break down of the separation of concerns, come to mind. If you know of any please let me know...
No comments:
Post a comment