Separated Presentation

Typically, a client application or Rich Internet Application (RIA) retrieves domain data, displays it in its user interface, and allows the user to view and modify the data through interaction with the user interface controls. Changes to the data are validated and then submitted by the application back to the data store. Defining all the application logic to control this process in the user interface controls makes them complex and difficult to understand, maintain, evolve, test and re-use.

Separated presentation patterns help you to cleanly separate out the visual portions of your application from the business and presentation logic portions. This is important for a number of reasons.

Having a clean separation between your application's user interface (UI) and underlying application logic means that you can unit test it independently of the user interface. Automated testing of application logic through the UI can be complex and time consuming to set up. In addition, it can be difficult to isolate errors in the user interface or application logic portions of your application when they are both tested at the same time.

Another key benefit of using a separated presentation pattern is that it allows application developers to focus on application logic while user interface designers can focus on the visual aspects of the application. This allows the appearance of the application to be defined separately from the underlying application logic; this makes it easier to maintain, modify (such as a result of usability feedback), or to customize.

Adopting a separated presentation pattern makes the application easier to understand and maintain. It also provides more opportunities for code re-use; this means application logic can be re-used in different parts of the same application, the user interface can be tailored to specific user roles or locales, or application logic can be shared between desktop and RIA versions of the same application. In all these cases, the underlying application logic is the same though its visual representation may be quite different.

Separated Presentation Patterns

There are a number of design patterns that support a separated presentation approach. Almost all these patterns separate out the user interface and application logic into three distinct components: a component that encapsulates the user interface, a component that encapsulates presentation logic, and a component that encapsulates the application's business and data management logic. There are variations between the various patterns because of the specific ways in which these three components interact with each other.

Separation of Concerns

Understanding and separating the various types of application logic, and the roles and responsibilities of the various separated presentation pattern components that encapsulate such logic, is the key to understanding and using any separated presentation pattern:

• Presentation logic is defined here as the application logic that is concerned with the application's use cases (or user stories) and that defines the logical behavior and structure of the application and that is independent of any specific user interface implementation. Separated presentation patterns often encapsulate presentation logic within Presenter or Presentation Model components. To maximize re-use opportunities, Presenters or Presentation Models should have no reference to any specific UI classes, elements, or controls, and they should be unit testable.
• Conversely, business logic is defined as any application logic that is concerned with the retrieval and management of application data and for making sure that any business rules that ensure data consistency and validity are imposed. Separated presentation patterns typically encapsulate business logic into Model components. To maximize re-use opportunities, Model components should not contain any behavior or application logic that is specific to a use case or user story.
• The specific user interface for the application is encapsulated into View components. Views are typically controls that are designed to work well in a separated presentation environment. Their specific role is to present the user with a user interface that represents the application's underlying data and logic in the most appropriate way and to interpret user input gestures and forward them to models or presenters that define how they affect the underlying data and application state. In some cases, the view may contain UI logic—application logic that is specific to the user interface implementation—in the view's code-behind file. In other cases, the view may be declaratively defined in XAML as a data template or control with no code-behind.

Presenter-First and View-First Composition

Regardless of the specific separated presentation pattern you use, your application can create and configure the view, presenter, and model components in a number of ways.

In presenter-first composition, the presenter is created first and then hooked up to a suitable view and a model. In view-first composition, the view is created first and then hooked up to a suitable presenter and a model. The Composite Application Library supports both types of composition. For more information, see the UI Composition design concept.

The creation of the views, presenters and models, and their association with each other, can be automatically and flexibly achieved using the Dependency Injection pattern. For more information, see Dependency Injection.

Separated Presentation Patterns in the Composite Application Library

The Composite Application Library uses two of the most commonly used patterns, the Supervising Presenter pattern and the Presentation Model pattern. These two patterns are both variants of the Model-View-Presenter pattern; they differ essentially in how they manage the view's interaction with the model:

• Supervising Presenter. This pattern is sometimes known as the Supervising Controller pattern. In this pattern, the view uses data binding to retrieve and update data directly from the model. The presenter coordinates any additional interaction between the view and the model that cannot be achieved through simple data binding. The presenter encapsulates presentation logic that interprets user gestures into actions against the model; it also changes in the model into user interface actions.
• Presentation Model. In this pattern, the presentation model provides a façade over the model and coordinates all of the view's interaction with it. The Presentation model is designed to be easily consumed by a view; this means the view can use data binding, commands, and other behaviors to interact with it. The Presentation model also frequently adapts the underlying model data into a form that is easier to represent in the user interface. The popular View Model pattern is a variant of this pattern.

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

Figure 1

Logical view of the Supervising Presenter and Presentation Model patterns

Each of these patterns has their own advantages and disadvantages. The following topics describes each pattern in detail and provides prescriptive guidance on how to choose between them:

• Supervising Presenter
• Presentation Model

More Information

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

• Separated Presentation on Martin Fowler's Web site

For more information about software design patterns applied in the Composite Application Library and Stock Trader Reference Implementation, see Patterns in the Composite Application Library.

Home page on MSDN | Community site