Model-View-Presenter

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Problem

A page in a Web application contains controls that display application domain data. A user can modify the data and submit the changes. The page retrieves the domain data, handles user events, alters other controls on the page in response to the events, and submits the changed domain data. Including the code that performs these functions in the Web page makes the class complex, difficult to maintain, and hard to test. In addition, it is difficult to share code between Web pages that require the same behavior.

Forces

• You want to maximize the code that can be tested with automation. (Views are hard to test.)
• You want to share code between pages that require the same behavior.
• You want to separate business logic from UI logic to make the code easier to understand and maintain.

Solution

Separate the responsibilities for the visual display and the event handling behavior into different classes named, respectively, the view and the presenter. The view class (the Web page) manages the controls on the page, and it forwards user events to a presenter class. The presenter contains the logic to respond to the events, update the model (business logic and data of the application), and manipulate the view state.

To facilitate testing the presenter, the presenter should have a reference to the view interface instead of the concrete implementation of the view. This approach allows you to easily replace the real view with a mock implementation to run tests.

View Updates

When the model is updated, the view also has to be updated to reflect the changes. View updates can be handled in several ways. The Model-View-Presenter variants, Passive View and Supervising Controller, specify different approaches to implementing view updates.

In Passive View, the presenter updates the view to reflect changes in the model. The interaction with the model is handled exclusively by the presenter; the view is not aware of changes in the model.

In a Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention. The presenter updates the model; it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required. Examples of complex UI logic might include changing the color of a control or dynamically hiding/showing controls. Figure 1 illustrates the logical view of the Passive View and Supervising Controller variants.

Figure 1

Passive View and Supervising Controller

The decision to use Passive View or Supervising Controller primarily depends on how testable you want your application to be. If testability is a primary concern in your application, Passive View might be more suitable because you can test all the UI logic by testing the presenter. On the other hand, if you prefer code simplicity over full testability, Supervising Controller might be a better option because, for simple UI changes, you do not have to include code in the presenter that updates the view. When choosing between Passive View and Supervising Controller, consider the following:

• Both variants allow you to increase the testability of your presentation logic.
• Passive View usually provides a larger testing surface than Supervising Controller because all the view update logic is placed in the presenter.
• Supervising Controller typically requires less code than Passive View because the presenter does not perform simple view updates.

Note

Note: In previous releases of the Web Client Software Factory, the View-Presenter pattern was introduced to describe the separation of the Web page in view and presenter classes. In the View-Presenter pattern, the presenter exclusively handles the interaction with the model and updates the view; the view is not directly bound to the model. Therefore, this approach is in line with the Passive View variant described in this topic.

Interaction with the Model

You can implement the interaction with the model in several ways. For example, you can implement the Observer pattern. This means that the presenter receives events from the model and updates the view as required. Another approach is to use an application controller to update the model.

Note

Note: For more information about the Observer pattern, see Exploring the Observer Design Pattern.

Liabilities

• There are more solution elements to manage.
• You need a way to create and connect views and presenters.
• The model is not aware of the presenter. Therefore, if the model is changed by any component other than the presenter, the presenter must be notified. Typically, notification is implemented with events.

Related Patterns

• Application Controller. You can make presenters interact with an application controller to avoid adding page flow and screen navigation logic to presenters and, therefore, making it easier to update the page flow.
• Model-View-Controller. The Model-View-Presenter and Model-View-Controller patterns have similar goals, although there are differences in how they achieve those goals.