Presentation Model

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 view in a composite application contains controls that display application domain data. A user can modify the data and submit the changes. The view retrieves the domain data, handles user events, alters other controls on the view in response to the events, and submits the changed domain data. Including the code that performs these functions in the view makes the class complex, difficult to maintain, and hard to test. In addition, it is difficult to share code between views that require the same behavior.

Forces

Any of the following conditions justifies using the solution described in this pattern:

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

Solution

Separate the responsibilities for the visual display and the user interface state and behavior into different classes named, respectively, the view and the presentation model. The view class manages the controls on the user interface and the presentation model class acts as a façade on the model with UI-specific state and behavior, by encapsulating the access to the model and providing a public interface that is easy to consume from the view (for example, using data binding). Figure 1 provides a logical view of the Presentation Model pattern.

Figure 1
Presentation Model pattern logical view

By using the Presentation Model pattern in a composite WPF application, developers can use the data-binding capabilities provided by Windows Presentation Foundation (WPF). With data binding, elements that are bound to application data automatically reflect changes when the data changes its value. Also, data binding can mean that if an outer representation of the data in an element changes, the underlying data can be automatically updated to reflect the change. For example, if the user edits the value in a TextBox element, the underlying data value is automatically updated to reflect that change.

A typical use of data binding is to place server or local configuration data into forms or other UI controls. In WPF, this concept is expanded to include the binding of a broad range of properties to a variety of data sources. In WPF, dependency properties of elements can be bound to common language runtime (CLR) objects (including ADO.NET objects or objects associated with Web services and Web properties) and XML data.

Note

For more information about data binding in WPF, see Data Binding.

When you implement the Presentation Model pattern in a Windows Presentation Foundation application, you can use data templates for your presentation model class and have Windows Presentation Foundation automatically apply the template for it to render the visual content. By doing this, developers keep the view code simple, and UI designers can focus on building the data templates. For more information about data templates, see Data Templating Overview.

Note

A variant of the Presentation Model pattern named Model-View-ViewModel is commonly used in Windows Presentation Foundation applications. For more information, see Tales from the Smart Client.

Example

To see an example implementation of the Presentation Model pattern, see the files WatchListPresentationModel.cs, WatchListView.xaml, and WatchListService.cs in the Stock Trader Reference Implementation (these files are located in the WatchList folder of the StockTraderRI.Modules.Watch project).

Liabilities

The Presentation Model pattern has the following liabilities:

• There are more solution elements to manage.
• You need a way to synchronize the view with the presentation model. Typically, this is done through data binding.
• The model is not aware of the presentation model. Therefore, if the model is changed by any component other than the presentation model, the presentation model must be notified. Typically, notification is implemented with the Observer pattern. For more information about the Observer pattern, see Exploring the Observer Design Pattern.

Related Patterns

The following patterns are related to the Separated Presentation pattern:

• Separated Presentation. This pattern is a specialization of the Separated Presentation pattern. Separated Presentation patterns are a category of patterns that focus on keeping the logic for the presentation separate from the visual representation.
• Supervising Controller. This pattern solves the same problems that the Presentation Model pattern solves; the main difference is that the Supervising Controller pattern separates responsibilities in different classes named, the view and the presenter, and the view interacts with the model for simple data binding.

More Information

For more information on Presentation Model, see the following:

• Presentation Model on Martin Fowler's Web site.

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.