Separated Presentation

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 then it 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 presentation logic from the business logic into different artifacts. The Separated Presentation pattern can be implemented in multiple ways; the following patterns provide prescriptive approaches to implement the pattern:

• Supervising Controller. This pattern, a variant of the Model-View-Presenter pattern, separates the responsibilities for the visual display and the event handling behavior into different classes named, respectively, the view and the presenter, and permits using data binding to enable direct communication between the view and the model.
• Presentation Model. This pattern, a variant of the Model-View-Presenter pattern, supplements a façade on the model with UI-specific state and behavior that is easy to consume from the view.

Figure 1 shows the logical view of the Supervising Controller and the Presentation Model patterns.

Figure 1
Logical view of the Supervising Controller and Presentation Model patterns

Liabilities

The Supervising Controller and the Presentation Model patterns have the following liabilities:

• There are more solution elements to manage.
• You need a way to create and connect the different artifacts that collaborate to provide the visual content.

Related Patterns

The following patterns are related to the Separated Presentation pattern:

• Presentation Model. This pattern is a specialization of the Separated Presentation pattern. This pattern separates the responsibilities for the visual display and the user interface state and behavior into different classes named, respectively, the view and the presentation model.
• Supervising Controller. This pattern solves the same problems that the Presentation Model pattern solves. This pattern separates the responsibilities in two classes, named respectively, the view and the presenter, and the view interacts with the model for simple data binding.

More Information

For more information on Separated Presentation patterns, see the following:

• Separated Presentation 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.