Introduction

Admittedly, I will not be particularly original this month as I plan to write about two well-known patterns such as Model-View-Controller (MVC) and Model-View-Presenter (MVP). If you google for these strings you can get as much as a few hundred of thousand relevant hits. I counted about 50,000 total hits if you search for something along the lines of MVC vs. MVP.

Just stopping at the links on the first page, you see in the titles some wording like “confused by…”, “succinct description…”, “what’s the difference…”. Overall, it means that while nearly any developers have a deep enough knowledge of both patterns, very few of them can effectively explain the difference. And, more importantly, very few developers can explain the difference in a way that is both correct and result convincing and believable to others.

Finding good descriptions of MVC and MVP is not hard and Google can point you quickly to a number of good references. For example, one good reference is this post in the Phil Haack’s blog: http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx.

So what’s missing that I might want to cover in this article?

All in all, I think that the overall perspective of GUI patterns is missing in many essays written in posts today. Personally I find it confusing a common statement such as “in MVC the controller processes the user’s gestures; in MVP, instead, it is the view.” From my viewpoint this is, first, a debatable point; second, not certainly the key difference between MVC and MVP.

To add more to confusion, in my very humble opinion, it is the Microsoft’s decision to use MVC in the name of the newest ASP.NET framework. There’s definitely a strong MVC flavor in the ASP.NET MVC framework; however, in terms of patterns, that is not the MVC pattern, but just a specific Web variation of it.

What is MVC exactly? And why MVP was introduced then as an improvement/replacement? And why MVP was then split in two other patterns?

In this article, you find a (necessarily brief) history of model-view patterns, from the first to appear (MVC) to MVP with a quick mention of the latest variations such as Supervising Controller and Passive View. If you’re somehow interested in the full story, you might want to check out Chapter 7 of the book “Microsoft .NET: Architecting Applications for the Enterprise”.

From Autonomous View to MVC

In the beginning of software, the presentation layer was made of monolithic, all-inclusive views. The user interacts with the view and the view captures the input, processes it internally, and then updates itself or moves to another view. This all-inclusive model is known as autonomous view. At a minimum, an autonomous view is hard to test.

As you can see, an autonomous view is dangerously similar to a Web or a Windows form you obtain by using the RAD facilities of Visual Studio without a grain of salt and due forethought. So back in the 1980s a better model was researched; the result was the Model-View-Controller (MVC) paradigm.

To achieve testability and separation of concerns in the user interface, the MVC pattern was introduced back in 1979 and first implemented in Smalltalk-80. Details of that implementation are presented in the paper you can find here. It is significant that the paper refers to MVC as a paradigm whereas today we call it a pattern. Is there any relevant difference or is it only the typical subtlety of architects? In software terms, a paradigm indicates the base class from which a variety of concrete design patterns derive. What does it mean actually?

The MVC pattern is clear in defining a triad of elements and their relationships. However, it also (deliberately?) leaves the architect a lot of freedom when it comes to implementation details. This is probably the reason why so many variations of MVC exist. This is probably also the reason why different implementations are anyway referred to as being MVC.

The primary goal of MVC is splitting the application in distinct pieces—the model, the view, and the controller. The model refers to state of the application, wraps the application’s functionalities, and notifies state changes to the view. The view refers to the generation of any graphical elements displayed to the user and captures and handles any user gestures. The controller maps user gestures to actions on the model and selects the next view. These three actors are often referred to as the MVC triad.

Before MVC, the code was basically developed by nesting calls from the user interface down to the core of the system. As in the figure below, with MVC three distinct actors come into play, each with a precise role.

Figure 1: From autonomous view to MVC.

What are the benefits of MVC?

The most obvious benefit is simplified testing of the presentation layer. However, by taking code out of the view you also encourage code structuring and the creation of logical layers—separation of concerns.

MVC Is Too Generic Of a Term

Originally, MVC was conceived to be a pattern for building the whole application and not just the presentation layer. Today, especially if you apply it to an enterprise class application, MVC is mostly about the presentation—view and controller. You use the MVC pattern for getting separation of concerns and testability in the presentation layer. The model is your business layer and if you end up with an extra layer of objects to model the data for the view, well, you likely enter the reign of another UI pattern—the Presentation Model pattern. (By the way, Presentation Model is what Microsoft calls M-V-VM, that is Model-View-ViewModel.)

My point is that MVC is, at the very end of the day, a blanket term and it addresses a number of concrete solutions where you use a distinct class to control any action subsequent to a user gesture and have an object to generate the next view for the user.

To understand MVC and contrast it to other similar patterns you should understand the mechanics of the elements of the triad. The sequence diagram in Figure 2 illustrates it.

Figure 2: TheMVC triad in action.

The model has some relationship to the view and gets invoked by the controller. This is the main point that led the transition to a slightly different pattern—the Model-View- Presenter (MVP) pattern—more specifically designed for large and complex applications.

Classic MVC has two big drawbacks. One is that the model needs to communicate to the view changes of state—typically through an Observer relationship. The other is that the view has intimate knowledge of the model.

The view is refreshed when it gets a notification of changes in the model; and how does it refresh? The view basically reads from model any information it needs and displays it through its UI elements. There’s no explicit contract that states which data the view needs precisely. As a result, the view needs to have its own logic to select data from the big model and massage it to UI elements. This code can hardly be taken out of the view.

As a result, the view is not as passive as it should be. And also, the view depends to some extent on the underlying platform or UI toolkit being used.

MVP and the Role of the Controller

The controller should be just a Mediator between the view and the rest of the application. This is not the case with plain MVC where responsibilities are more distributed. By giving the controller the power to govern the rendering of the view while interacting with the model, you put it at the center of the universe.

By defining a contract for the view, you automatically make the presentation layer even more testable, as the view is now mockable and can be replaced with another view class implementing the same contract. This enables two interesting scenarios.

First, the presentation logic gains independence from the UI platform and, for instance, the same controller class can be reused in Windows and Web presentation layers. Second, the same controller class can work with different views of the same application. This is an important achievement in regard to the Software as a Service (SaaS) deployment model. In a SaaS scenario, an application is hosted on a Web server and offered as a service to customers.

MVP is a derivative of MVC aimed at providing a cleaner separation between the view, the model and the controller. The pattern was originally developed at Taligent in the 1990s. The paper you find here offers an introduction to MVP that describes how and why the pattern was devised.

Starting from the MVC triad, creators of MVP neatly separated Model from the View/Controller pair, which they called Presentation. The core of MVP is the strictly regulated interaction taking place between the view and the controller. In MVP, the controller was renamed to presenter. The figure below offers a graphical comparison of MVP and MVC.

Figure 3: Comparing the mechanics of MVP and MVC

Summarizing, you could say that MVP is a refinement of MVC based on three facts:

• View doesn’t know Model;
• Presenter ignores any UI technology behind the View;
• View is mockable for testing purposes;

In addition, by extracting an interface out of Model, you enable a Presenter-First scenario where both the View and the Model are mockable for testing purposes.

What About the MVC in ASP.NET MVC?

MVC was devised at a time in which the Web was still to come. On the other hand, the loose definition of MVC just leaves room for frameworks to specialize MVC to particular areas, including the Web. This was just the case for Model2—an extremely popular Web variation of MVC. You can find detailed information on the pattern here. Model2 is a pattern that was originally created for developing with Java Server Pages and owes a lot of popularity to the Struts framework.

OK, wasn’t I supposed to talk about ASP.NET MVC in this section? Where’s the plug to ASP.NET MVC in the Model2 pattern?

ASP.NET MVC is just an implementation of the Web variation of MVC known as Model2.

In a Model2 application, requests flow from the browser directly to the controller (via a HTTP handler). The user interface of a Model2 application offers HTML input elements and all of them cause a link to be followed and a HTTP post. On the Web server the request is captured and transformed into a method call on the selected controller. As the controller’s method returns, the controller orders the view to render out to HTML. The view receives fresh data for its response directly from the controller. The output of the view is delivered to the front controller and sent back to the browser.

In Model2, we can really say that the controller is the entry point in the flow and the view is extremely thin and passive—except for some JavaScript you may insert.

Model2 and ASP.NET MVC are a bit different from the classic MVC formulation. To me, they look closer to MVP but are still different from it. In particular, the difference lies in the fact that no contract is required for the view—though you can force it in your application. In addition, the controller is not completely a Mediator.

Summary

This is supposed to be a short and concise article. Therefore, it’s time to summarize. My feeling is that today classic MVC is gone, but some of its variations are healthy and thrive. They are Model2 for the Web and MVP for both the Web and Windows. MVP is also going to become a blanket term. On July 2006, in fact, Martin Fowler proposed to retire MVP entirely and replace it with two variations—Passive View and Supervising Controller—based on the amount of logic you decide to put in the view and in the definition of the contract for the view. But this is possibly stuff for another article.

About Dino Esposito

Dino Esposito is one of the world's authorities on Web technology and software architecture. Dino published an array of books, most of which are considered state-of-the-art in their respective areas. His most recent books are “Microsoft ® .NET: Architecting Applications for the Enterprise” and “... This author has published 53 articles on DotNetSlackers. View other articles or the complete profile here.

---

Discussion

Subject	Author	Date
Fully agree with you	Ran Davidovitz	1/16/2009 9:35 AM
As discussed in previous meetings we had, i fully agree with you on your vision on things, i personally tend to like to use the passive view. in my active project i use MVC (asp.net) ONLY for restfull application structure as i use full client centric approach (save some bytes). Reply | Permanent link
Examples	Robert Rolls	1/17/2009 5:35 PM
I think that it's theoretical and as such what's really needed is a concrete example in code of the different implementations being presented. Stating that the controller 'mediates/handles user gestures' may mean very little to junior or less experienced developers, the very people we're trying to teach the pattern to. There seems to be a lot of talk but very few concrete examples of each pattern deviation - any takers? Reply | Permanent link

---

Please login to rate or to leave a comment.