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 3 – Model View Presenter

Considered a descendant of Model View Controller, MVP comes in two main forms, which patterns god Martin Fowler calls Supervising Controller and Passive View. A significant variant of Passive View is the Humble View, which is epitomized by Michael Feathers' classic article The Humble Dialog Box, and a very significant variation of that is Presenter First.

Most discussions of MVP begin with MVC and proceed in chronological order, but I find this ordering illogical. From a practical standpoint, the primary reason to choose MVP is to increase testability of your UIs, so the logical starting point is the Humble View form of Passive View.

Passive View MVP

Passive View MVP

Dotted lines represent communication by events while solid lines are direct object messages. The roles of the components are as follows.

View: In this architecture the view is kept as "humble" (that is, as free of code and logic) as possible. UI technology is often difficult to unit test (though as Fowler says, this point is often over-stated) so the goal of Humble View is to remove anything from the view that might be worth testing. The view will generally not be covered by unit tests at all in this architecture.

Presenter: The view simply passes notification of user stimulus to the presenter, whose role is similar to a controller in MVC. The presenter accesses the view only through a UI-agnostic interface so that it can be easily mocked in unit tests. The presenter updates the model appropriately and can receive events from the model when its state changes. The presenter is entirely responsible for updating the view; the view has no direct knowledge of or interaction with the model. The reason for this is to simplify the logic and make the code more readable and maintainable by putting all UI manipulation code in a single place.

A presenter differs from a controller primarily in its granularity: presenters are created at the form/page/complex widget level, and not at the widget/window level as are controllers. Also in Passive View MVP presenters are responsible for updating the view as well as for responding to user interaction, while controllers are only responsible for the latter.

Model: As with MVC, the model has no knowledge of the presenter or the view.

Some other variations on Passive View:

Passive View MVP with a Presenter-Model Observer

By removing the View's direct knowledge of the presenter you can decouple the view from the presenter and allow the same view to be used with different presenters. There is however a penalty to be paid in loss of readability whenever the Observer pattern is used, and this can sometimes be significant.

Passive View MVP with a Model Interface

By adding an interface for the model you can improve testability of the presenter yet again. This can be used with or without the Presenter-View Observer. In fact I would encourage use of a model interface for all but the most trivial of models. At this point we've arrived at the MVP variant used by Presenter First, though Presenter First is really a variation of TDD, and so is as much a design/development process as an architecture.

It should be noted that Fowler considers the View interface optional, but from a practical standpoint we can assume its existence.

Supervising Controller

Historically, Supervising Controller was developed before Passive View, but logically it's the pattern you revert to in order to take advantage of data binding:

Supervising Controller MVP

With this pattern you would allow data binding of the model to the view to handle the "easy" synchronization work, and would reserve the presenter for handling any complex logic. Although this is structurally more complex than Passive View, in practice where data binding is strong it can result in far simpler code. The Presenter-Model Observer has been removed from the diagram above, but there's no reason it couldn't be added back if that were appropriate for the situation.

For additional variations on MVP, I found this to be an interesting post. I will reserve creation of MVP code samples for a future post.