Supervising Controller

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 event handling behavior into different classes named, respectively, the view and the presenter. The view class manages the controls on the user interface and 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, in turn, manipulate the state of the view.

To facilitate testing the presenter, the presenter has a reference to the view interface instead of to the concrete implementation of the view. By doing this, you can easily replace the real view with a mock implementation to run tests.

View Updates and Interaction with the Model

When the model is updated, the view also has to be updated to reflect the changes. View updates can be handled in several ways. With the Supervising Controller pattern, the view directly interacts with the model to perform simple data binding that can be declaratively defined, 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 Supervising Controller pattern.

Figure 1
Supervising Controller logical view

By using the Supervising Controller 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.

Example

To see an example implementation of the Supervising Controller pattern, see the files TrendLinePresenter.cs, TrendLineView.xaml, and TrendLineView.xaml.cs in the Stock Trader Reference Implementation (these files are located in the TrendLine folder of the StockTraderRI.Modules.Market project).

Liabilities

The Supervising Controller pattern has the following 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 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.
• Presentation Model. This pattern solves the same problems that the Supervising Controller pattern solves; the main difference is that the Presentation Model pattern separates responsibilities in different classes named, the view and the presentation model.

More Information

For more information on the Supervising Controller pattern, see the following:

• Supervising Controller on Martin Fowler's Web site.
• Model-View-Presenter Pattern on MSDN.

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.