Or, as my recent inbox tells me, you’re not afraid to ask. ;)

A coworker recently asked for some good resources on getting up to speed on the Model View Controller (MVC) pattern. Around the same time, I received another email talking about how people are confused around the difference between MVC and the Model View Presenter (MVP) pattern.

mvcNo better opportunity to apply the DRY principle by answering some of these questions with a blog post.

MVC

The first place to start digging into the MVC pattern is to look at the Wikipedia entry. That’ll get you a nice brief summary of the pattern along with a list of resources.

In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

trygve If you’re really into it, you can go directly to the source and read the original papers from Trygve Reenskaug, the inventor of the pattern.

There you’ll learn from the original paper (pdf) that the initial name for the pattern was Thing-Model-View-Editor. The pattern was baked via a process of extracting, improving, and articulating existing command and control patterns used in the operation of Norwegian ship yards in order to streamline and improve operations.

MVP

That ought to get you going with the MVC pattern. Now onto Model View Presenter, which was a response to the inadequacies of the MVC pattern when applied to modern component based graphical user interfaces. In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller.

MVP was popularized by Taligent in this paper on the subject (pdf). More recently, Martin Fowler suggested retiring this pattern in favor of two variants: Supervising Controller and Passive View.

The Difference?

So what’s the diff between MVC and MVP? Using GitHub, here it is!

246

Sorry, bad joke but I couldn’t resist.

The two patterns are similar in that they both are concerned with separating concerns and they both contain Models and Views. Many consider the MVP pattern to simply be a variant of the MVC pattern. The key difference is in how both patterns solve the following question: Who handles the user input?

With MVC, it’s always the controller’s responsibility to handle mouse and keyboard events. With MVP, GUI components themselves initially handle the user’s input, but delegate to the interpretation of that input to the presenter. This has often been called “Twisting the Triad”, which refers to rotating the three elements of the MVC triangle and replacing the “C” with “P” in order to get MVP.

What About The Web?

If you were playing close attention, most of these articles focus on rich client applications. Applying these patterns to the web is a very different beast because of the stateless nature of the web.

ASP.NET WebForms, for example, attempts to emulate the rich client development paradigm via the use of ViewState. This is why many attempts to apply patterns to ASP.NET focus on the MVP pattern because the MVP pattern is more appropriate for a rich client application with GUI components. A while back I even tossed my Supervising Controller sample into the ring. The Patterns and Practices group at Microsoft ship an MVP Bundle for ASP.NET.

However, many web platforms embrace the stateless nature of the web and forego attempting to simulate a state-full rich client development environment. In such systems, a tweaked MVC pattern is more applicable.

This pattern has been adjusted for the Web for your application development enjoyment.

AFAIK, Struts, a Java web framework, is one of the first widely used web frameworks employing the MVC pattern, though most people now look at Rails as being the tipping point that really brought MVC to the web and popularized the MVC pattern for web applications.

ASP.NET MVC is a new (in development) alternative framework for ASP.NET developers that makes it easy for developers to follow the MVC pattern. This framework employs the MVC pattern rather than the MVP pattern because it does not attempt to emulate rich client development, and thus the MVC pattern is more appropriate.

More Reading

There’s a lot of good content out there that puts these patterns into historical and categorical perspective. Besides the links already mentioned in this paper, I recommend checking out…