Presentation Patterns : MVC, MVP, PM, MVVM

In this blog post, I will explain different presentation patterns, why do we need these patterns and how to use them.

Why do we need these patterns ?  

Why do we need these patterns in  the first place ? Well one can certainly build software applications without using any of these patterns, but by using these patterns we can achieve separation of concerns design principle. These help in improving maintainability of the application. Another important reason why these patterns became popular is implementing these patterns improve the testability of the application using automated unit tests. We all know how difficult it is to write unit tests for UI tier, these patterns try to address some of these difficulties and provide a way of increasing application’s testability.

As the name suggests these are applicable to only Presentation tier.  Model View Controller (MVC) was the first pattern that was developed by Trygve Reenskaug in 1979 for SmallTalk applications. It was developed to build the complete applications not only the presentation layer. Those days there were no UI controls and everything had to be drawn from scratch and handle interaction between your program and user input devices such as keyboard.  Presentation layer has changed a lot since then, so did the definition of the pattern. Today’s MVC pattern definition doesn’t exactly match the original definition. A number of variations of this pattern have been adapted.

I will explain the classic MVC pattern first and then introduce a web variant of it, known as Model 2, then move on to MVP, explain the two different variations of MVP pattern and then Presentation Model (PM) and its variant MVVM. The below diagram from “Architecting Applications for the Enterprise” by Dino Esposito and Andrea Saltarello’s book depicts the main presentation patterns and their variations

The Classic Model-View-Controller Pattern (MVC):

The following diagram depicts the structure of MVC pattern

In MVC pattern, model, view, controller triad exists for each object that can be manipulated by the user. Lets see what each of these does

Model : Model means data, that is required to display in the view. It can sometimes be the exact data entities that are retrieved from the business layer or a variation of it. Model encapsulates business tier. 

View : View is something that displays data to user. In MVC pattern view should be simple and free of business logic implementation. View invokes methods on Controller depending on user actions. In MVC pattern View monitors the model for any state change and displays updated model. Model and View interact with each other using the Observer pattern.

Controller: Controller is invoked by view, it executes interacts with the model and performs actions that updates the model. Controller doesn’t have an idea about the changes that it’s updates on the model resulted in the view. Often misunderstood in MVC pattern is the role of Controller. It doesn’t mediate between the view and model,and its not responsible for updating the view. It simply process the user action and updates model, its the view’s job to query and get the status of the changed model and render it.  The only time Controller comes into picture is if a new view has to be rendered. 

A more easier way of understanding the interaction between Model, View and Controller is using a sequence diagram, which I took from Dino Esposito’s excellent book.

In Classic MVC pattern Model and View are bound according to the rules of Observer pattern. This is one of the major drawback of Classic MVC pattern. The Classic MVC pattern is no longer in use today. Model2 is a popular variant of MVC pattern that is used in web applications

MVC Pattern for Web Applications (Model 2) 

Classic MVC pattern was designed when web didn’t exist and it was primarily designed for desktop applications (We are talking about the 70’s :-)), but the loose definition of MVC made way to different variations of MVC. One of the most popular variation is Model 2. It’s a pattern originally created for Java Server Pages (JSP) and owes a lot of its popularity to Struts framework.  It’s the same pattern implemented by the recent ASP.NET MVC framework in .NET technology stack.

In Model 2 pattern, all web post requests go to front controller, implemented as a http interceptor (http module in ASP.NET ),which in turn figures out the appropriate controller depending on the structure of the incoming request URL and services the request. The controller invokes a method that affects the model.

The following diagram depicts the structure of Model2 pattern:

The main difference between classic MVC and Model2 is that there is no direct contact between view and model. The Model in this pattern is not your typical business entities or Business layer, it’s more of a ViewModel that captures the state of the view.  The controller will be the one who will talk to BLL and update the model.  The interaction between the view and model is an indirect relationship.

Below sequence diagram depicts Model2 interactions using sequence diagram :

Model2 is the most popular variant of MVC pattern applied to web applications, Model2 is MVC adapted to web. 

Model View Presenter (MVP)

Classic MVC pattern has two drawbacks:

1. Model needs to communicate change of state to the view
2. The view has complete knowledge of the model, there is no explicit contract between view and model , which means the view is not as passive as it should be.

Model View Presenter (MVP) pattern evolved from MVC, it tries to address the above concerns. MVP was originally developed at Taligent, in 90’s. The original MVP is also no longer in use today. According to Martin Fowler, you never use MVP, rather you use Passive View or Supervising Controller or both variants.

The MVP pattern neatly separates the Model from the View and breaks the direct relationship between them. The core of MVP is the interaction between View and Presenter. The View exposes a contract(interface in .NET) through which the Presenter interacts with the View. When users interact with the view, the view invokes a method on the presenter and the presenter performs the required task on the Model and then updates the View using the contract.

Below sequence diagram depicts the MVP pattern in action

Model : Model in MVP represents business entities or domain model or object model of the business tier. 

View : In MVP pattern, View is light weight. It should only have the UI elements and shouldn’t be aware of the model. But that is in a ideal scenario, building a real passive view is quite complex in practice, hence the implementation of MVP falls into two categories :
1. Passive View :
         The view is really passive, light weight.
         View doesn’t know the model

The below triad diagram aptly depicts the Passive View pattern

2. Supervising Controller
        The view is active, binds the view using data binding or simple code in view
      View doesn’t know the model

The below triad diagram depicts Supervising Controller pattern in action.

Presenter :
Why Presenter? Why the name change? The classic MVP triad diagram looks similar to MVC diagram, the noticeable difference is Controller replaced with Presenter. It’s not a case of just name change. The Presenter in MVP, presents user actions to the backend system; after getting the response it presents the response to the users, whereas the Controller in the MVC pattern doesn’t mediate between Model and the View, it doesn’t update the view, it just mediates between user actions and model.

MVP became quite popular in .NET world. Though it involves significant effort in using MVP pattern to build UI applications it pays of while building large scale enterprise applications, but probably a over kill for small applications.

Presentation Model (PM)
Martin Fowler developed Presentation Model pattern for Presentation layer. So what’s the difference between MVP and PM ? It adheres to the same fundamental principle, Separation of Concerns. It differs in the view Model is defined and the tasks Presenter performs.

This particular pattern is well suited for rich UI applications and it really suits the latest advances in UI technologies. Presentation Model suits well for WPF and Silverlight applications. MVVM is the variation of PM pattern implemented in WPF and Silverlight.

Lets see how the interaction diagram looks for Presentation Model pattern

In MVP, Presenter talks to the View using a contract (interface in .NET) , but in PM the view doesn’t implement any interface. The view elements are directly bound to properties on the model. In PM, the view is passive.The Presenter goes by the name Presentation Model in this pattern.

Model:  Here the Model is not your typical business entities or business objects it represents the state of the view, it might contain UI elements specific properties and once the model is constructed, view will be ready for rendering.

View : View is light weight and simple. It will contain only UI specific elements. Any events raised by the user are transmitted to the presenter (Presentation Model) , the Presentation Model, updates the model with the results it gets. The presenter after updating the model orders the view to render.
Presenter: The presenter in PM receives events from view, processes them, updates the model as in MVP or MVC, but the difference is in PM the presenter holds the model object and its responsible for updating the state changes and calling the view to render once the model is updated.

Model View View Model (MVVM)
In 2005, John Gossman, Architect at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler’s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View’s state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF and Silverlight to simplify the creation of user interfaces. MVVM is a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms to leverage core features of WPF such as data binding, commands , templates.

This diagram take from MSDN depicts MVVM Pattern in action.

View : View in MVVM is similar to view in PM. It contains only the UI elements. The interaction between view and ViewModel happens using Data Binding, Commands and Notifications implemented through INotifyPropertyChanged interface.
ViewModel: View Model is equivalent to PresentationModel in PM pattern, it encapsulates presentation logic and data for the view.  ViewModel contains the state of the view and uses Commands , DataBinding and Notifications to communicate with the view.
Model: Model is Business logic layer of the application

When you use MVVM pattern for WPF, Silverlight the view wouldn’t have the typical event handlers that’s so common in UI code, All user actions are bound to commands, which are defined in the ViewModel and invoke the necessary logic to update the model. This improves unit testability of MVVM applications.

Conclusion: MVC, MVP, PM, MVVM all are different ways of implementing the Separation of Concerns (SoC) principle. The different variants show how the pattern changed with the changes in UI technologies in both desktop and web applications. As long as you understand the fundamental SoC principle you would easily understand these patterns.