How to: Implement the Model-View-Presenter Pattern | How to: Unit Test the Presenter | Model-View-Presenter QuickStarts

Model-View-Presenter Pattern

This topic describes the Model-View-Presenter pattern and two variants: Passive View and Supervising Controller.

Problem

A page in a Web application contains controls to 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. Writing this code in the Web page (the code-behind class) 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 the share code between pages that require the same behavior.
  • You want to separate business logic from UI logic to make it easier to understand and maintain.

Solution

Separate the responsibilities for the visual display and the event handling behavior into different classes, the view and the presenter. The view class (the Web page) manages the controls on the page, and it forwards 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, in turn, manipulate the state of the view.
To facilitate testing the presenter, make the presenter have a reference to the view interface instead of to the view concrete implementation. By doing this, you can easily replace the real view with a mock implementation to run tests.

View Updates

When the model is updated, the view 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 implement 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 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.
PassiveViewAndSupervisingController.png
Figure 1
Passive View and Supervising Controller.

The decision to use Passive View or Supervising Controller lies primarily on the testability level that you want to achieve for your application. 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 you do not have to write code in the presenter to update the view for simple changes. 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 collaborate in simple view updates.
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. Thus, 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 and have the presenter listen to events of the model and update the view as required. Another approach is to use an application controller to update the model.

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.
How to: Implement the Model-View-Presenter Pattern | How to: Unit Test the Presenter | Model-View-Presenter QuickStarts

Last edited Dec 5, 2007 at 11:24 AM by ejadib, version 2

Comments

No comments yet.