From a recent blog, you may have gathered that I’ve recently been conducting some interviews and as they were for web application developers a question I asked was “can you explain what the MVC pattern is?”, and to their credit, every candidate knew the answer. For those of you who don’t know, MVC stands for Model, View, Controller and is a design pattern used to separate the business, data and presentation logic of an application into discreet components. There are many definitions on the web of the MVC pattern’s components, so at the risk of confusing things even more, here are mine:
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.
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.
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.
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.
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...