Tom’s Patterns Cheat Sheet, Part 5 – Presentation Model

Overview

Presentation Model (also called Application Model) is a pattern that is similar to the MVC family of patterns in that it consists of a domain model, a view and a "something else" that acts as a mediator between the model and the view.

That "something else" is the presentation model. A presentation model differs from the controller in MVC and the presenter in MVP primarily in the way it is conceived. A presentation model is conceptually an object model that represents the view. E.g. if your view contains two textboxes and a checkbox, you would expect to see two string properties and a boolean property in the presentation model:

Simple Presentation Model Example

In this example, the logic associated with enabling or disabling the "Offline enabled" checkbox is handled by the presentation model, as is the code that interacts with the domain model, which is in this case the authentication service.

Controllers and presenters, in contrast, are conceptually handler classes that act as conduits between the domain model and the view. A presentation model is stateful, because it is considered the "system of record" for view state, while presenters and controllers are likely to be stateless. In fact Fowler comments that "the basic MVC notion assumes that all the state of the view can be derived from the state of the model," so in classic MVC there is no view state.

Controllers, using Martin Fowler's description of MVC, tends to be very granular - one ore more controllers for every widget. Presenters tend to be more large-grained - typically one per form. Presentation models tend to be larger-grained as well, similar to presenters, although composition of presentation models is also common, particularly in the Model-View-ViewModel (MVVM) variant used by WPF developers.


Components of Presentation Model

The presentation model: An abstraction for a view's state and behaviors. Like the presenter in MVP, the presentation model is intended to be free of UI dependencies, and for the same reason: One of the primary motivations for Presentation Model is to improve the testability of the system by moving as much logic as possible out of the view, where it is difficult to test.

The view: As in MVP, the view in the Presentation Model pattern is intended to be as free of logic as possible, again to improve testability.

The domain model: The domain model is conceptually the same in Presentation Model as in MVP.


Variations of Presentation Model

Fowler identifies two variations of Presentation Model, one in which the view references the presentation model, and one in which the presentation model references the view:

Presentation Model pattern in which the View references the Presentation Model

Presentation Model pattern in which the Presentation Model references the View

Fowler provides a code sample of the first variant here. This variant is simpler than the second one, especially in cases where data binding can be used or where the Presentation Model->View observer can be dispensed with, because the presentation model has no dependencies on the view at all, or even on a view interface.

But if data binding is not available and if you want to test the code that synchronizes the presentation model's state with the view, then the presentation model will need a reference to the view, so the second option is required. Another important variation is MVVM, which is used extensively by the WPF community. I will attempt to comment on that pattern in the next post.


Pros and Cons of Presentation Model

As with MVP, one of the main motivations for using Presentation Model is to improve the testability of the system.

As with any Separated Presentation pattern, following the pattern may make it easier to support multiple views or to change UI technologies, although in practice this benefit is often overstated.

As with MVC and MVP, Presenter Model allows you to separate the UI technology from the UI logic, which makes the code easier to understand and to maintain. Compared to MVP, Presentation Model can lead to a cleaner, simpler presenter / presentation model object model, because by encapsulating view state as well as behavior the presentation model disentangles itself entirely from the view.

Presentation Model may lend itself better than MVP to situations in which you want to create an automation object model for your user interface that would be usable by SDK programmers, because the presentation model object model is closer to what a programmer would expect to see in an automation object model. Although some developers have exposed the MVP presenter for use in this way, they generally are not as user-friendly as presentation models.

On the downside, because it maintains its own view state, Presentation Model introduces the need to synchronize the view and the presentation model, although this can be mitigated by data binding. It makes use of the Observer pattern, which decreases readability and maintainability of the system. And it increases the number of moving parts in the system, which can decrease maintainability in small applications.

Tom’s Patterns Cheat Sheet, Part 2 – Model View Controller

MVC is one of the oldest, most widely known architectural patterns. It involves decomposition of the system into three parts, using terminology from patterns god Martin Fowler's GUI Architectures paper:

• Model: domain object model.
  
• View: user interface that displays the state of the model.
  
• Controller: an object that receives user input and updates the model, and possibly the view.
  

Here's the usual MVC dependency diagram:

This means the model is independent of (has no knowledge of) the views and the controllers, the view and the controller have strong knowledge of the model, and the controller has knowledge of the view. So we would expect, for example, to be able to make drastic changes in the view without affecting the model at all, but changes in the model will probably mandate changes in the view.

MVC has two primary uses: rich client GUIs and thin client Web applications. It was originally developed for rich client UIs, but in that space it has mostly been superseded by other patterns. But it's alive and well in the web space, and is the basis of both Ruby on Rails and ASP.NET MVC. See this MSDN article for a good overview.

MVC in Rich client GUIs: mainly uses a variant called active model. "Active" because the model takes action (notifies an observer, raises an event) that lets views and controllers know when its state has changed. The general data flow goes like this:

• User stimulus happens, controller receives the event (often without the view's involvement at all)
  
• Controller updates the model
  
• Model raises a data changed event
  
• View traps the event and updates itself
  

Graphically this looks as follows. A good example of this can be found here.

Dotted lines are used to indicate communication via events, solid lines to indicate direct manipulation. Some notes:

• There may be multiple views and multiple controllers working off a single model.
  
• The controller and the view don't depend on one another in this picture. Martin Fowler actually leaves the controller -> view dependency off his dependency chart because, he says, it's not often used in the rich client GUI case. It is used commonly in the web case however.
  
• This is often implemented at a very low level of granularity – one MV pair for each widget, or even for each window in each widget.
  
  • In that case the "model" may represent a value stored in a widget, and not in a database.
    

Pros:

• Separation of model from view. Allows changes in the view without affecting the model. Good for cases where the views change more frequently than the model, as is usually the case.
  

Cons:

• Use of observers/events increases complexity.
  
• Frequent updates to the model could result in many data changed events and suboptimal performance.
  
• Separates view from model writes, but not from model reads. Since views are difficult to unit test, this means logic involved in transforming model data for presentation is not covered.
  

MVC in Web applications:

Uses a variant called passive model. "Passive" because the model makes no effort to inform anyone that its state has changed. Flow is as follows:

• HTTP request happens, controller on the server receives the request.
  
• Controller updates the model, usually resulting in a database update.
  
• Controller selects the view appropriate for the request, provides it with any model data it needs, and returns it, typically in the form of HTML, XML or JavaScript.
  
• The browser renders the view.
  

This looks like any well factored web application that you've ever seen, in which the domain model is carefully separated from the web UI code, but there is an important difference. In MVC web applications the web UI code is separated logically and physically into separate view and controller elements. Some notes:

• The view is as simple as possible, usually just an HTML template containing some simple server-side code snippets.
  
• The controller is designed for maximum testability. In the case of ASP.NET MVC, it is free of UI and web server dependencies, which the ASP.NET MVC framework provides to the controller via easily mocked interfaces. In the case of Rails, controllers are designed to be easily testable using functional tests.
  
• The view and controller are larger grained than in the rich-client case, generally at the level of one controller/view per page.
  

Pros:

• Separation of controller from model helps manage complexity of large web applications.
  
• Designed to support Test Driven Development (TDD).
  

Cons:

• For small to medium sized web applications, increases complexity.