Note:
This topic is duplicated in the documentation so that you can read all the pertinent information within a single section.

The typical implementation process of the Model-View-Presenter pattern includes the following tasks:

1. Implementing a presenter class. The presenter should handle user events, update the model, and manipulate the state of the view.
2. Implementing a view interface. The view interface should expose the view’s state elements.
3. Implementing a view class. The view contains user interface artifacts. The view should forward user events to the presenter and expose properties that allow the presenter to manipulate the view’s state.

Implementing a Presenter Class

The presenter should handle user events, update the model, and manipulate the state of the view. Usually, the presenter is implemented using Test Driven Development (TDD). Implementing the presenter first allows you to focus on the business logic and application functionality independently from the user interface implementation.

When implementing the presenter, you also need to create simple view and model objects to express the interaction between the view, the model, and the presenter. In order to test the presenter in isolation, make the presenter reference the view interface instead of the view concrete implementation. By doing this, you can easily replace the view with a mock implementation when writing and running tests. A similar approach can be followed for model artifacts.

Interaction with the View

The communication with the view is usually accomplished by setting and querying properties in the view to set and get the view’s state, respectively. For example, a view could expose a Customer property that allows the presenter to set the customer that the view should display. Another valid approach consists of invoking methods on the view. For example, the presenter could invoke a method named ShowCustomer(Customer) that indicates to the view that it has to display the customer passed by parameter.

For example implementations of presenter classes, see the ContactDetailPresenter and ContactsListPresenter classes in the Model-View-Presenter QuickStart. These classes are located in the Views folder of the Contacts project.

Testing the Presenter

For details about how to test the presenter, see How to: Unit Test a Presenter.

Implementing a View Interface

The view interface should expose the view’s state. Typically, a view interface contains properties for the presenter to set and query the view’s state. Exposing properties over methods in the view usually keeps the presenter simpler because it does not need to know about view implementation details, such as when data is to be bound to user interface controls.

Depending on how the view interacts with the presenter, the view interface might also have additional elements. If the view interacts with the presenter by raising events, the view interface will include event declarations.

The following code from the Model-View-Presenter QuickStart illustrates a view interface definition.

public interface IContactDetailView
{
    void LoadStates(ICollection<State> states);
    void SetViewReadOnlyMode(bool readOnly);
    void SetViewControlsVisible(bool visible);
    void ShowCustomer(Customer customer);

    ContactDetailPresenter Presenter { get;}
    event EventHandler EditClicked;
    event EventHandler<DataEventArgs<Customer>> SaveClicked;
    event EventHandler DiscardChangesClicked;
    event EventHandler UserControlLoaded;
}

Implementing a View Class

The view (a Web page, a user control, or a master page) contains user interface elements. The view should forward user events to the presenter and expose properties or methods for the presenter to manipulate the view’s state.

If you are using the Supervising Controller variant, the view should also perform direct data binding to the model (for example, using the ASP.NET built-in ObjectDataSource control). In cases where the presenter exclusively handles the interaction with the model, the ObjectContainerDataSource Control control will help you implement data binding through the presenter. The ObjectContainerDataSource control was designed to facilitate data binding in a Model-View-Presenter scenario, where the view does not have direct interaction with the model.

Interacting with the Presenter

There are several ways that the presenter can forward user gestures to the view. In one approach, the view directly invokes the presenter’s methods. This approach requires you to implement additional methods in the presenter and couples the view with a particular presenter. Another approach consists of having the view raise events when user actions occur. This approach requires code in the view to raise events and code in the presenter to subscribe to the view events. The benefit to the second approach is that there is less coupling between the view and the presenter than with the first approach.

For example implementations of view classes, see the ContactDetail and ContactsList classes in the Model-View-Presenter Quickstart. These classes are located in the Contacts folder of the MVPQuickStart Web application project.

Solution Structure

Typically, you store presenter classes and view interfaces in a class library project and view implementations (Web pages, user controls, or master pages) in a Web site or Web application project. Figure 1 shows the Model-View-Presenter QuickStart solution.

Figure 1
Model-View-Presenter QuickStart solution

Using Automation to Implement the Model-View-Presenter Pattern

The guidance package adds automation to Visual Studio that allows developers to easily perform common development tasks. The guidance package includes three recipes (automated tasks) that you can execute to implement the Model-View-Presenter Pattern in a Composite Web client solution:

• How to: Add a Page with a Presenter. This helps you to add a new view class and the associated presenter class to an existing business module. It adds the class files that implement the Web page, an interface for the page, and the corresponding presenter.
• How to: Add a Master Page with a Presenter. This helps you to add a new master page and the associated presenter class to an existing business module. It adds the class files that implement the master page, an interface for the master page, and the corresponding presenter.
• How to: Add a User Control with a Presenter. This helps you to add a new user control and the associated presenter class to an existing business module. It adds the class files that implement the user control, an interface for the user control, and the corresponding presenter.

Figure 2 shows the Web Client Factory shortcut menu that appears when you right-click a folder in a Web site.

Figure 2
The Composite Web Client Automation automates common development tasks

For information, including download information, see Guidance Automation.