This article explains the advantages of the Presentation Model pattern over the Model-View-Controller and Model-View-Presenter. This will improve your decisions about GUI implementations for desktop.

One of the major challenges in the development of desktop software is the effective use of unit tests that cover the GUI functionalities and its interactions with the remainder of the software. The complexity of this implementation lies in the control of selected items in lists and tables, modal dialogs, clicks and events. In fact, it is extremely difficult to develop good tests on the GUI when the application logic is tightly-coupled to UI components.

You probably have already heard about design patterns that could help in this case, especially those that separate the application logic from UI components. Perhaps the most famous is the Model-View-Controller (MVC), which has been widely used not only for desktop applications but also for web development.

There is a relevant question that we should ask ourselves at this point: Is this separation between logic and UI components enough to reduce the complexity of writing GUI unit tests?

Figure 1 presents the three most important presentation patterns for desktop development. Besides the MVC, there is one called Model-View-Presenter (MVP) that consists of a small variation of the first one (see Martin Fowler’s description of them for more details).

Figure 1: Patterns for desktop application development.

The important thing to notice in this picture is that both MVC and MVP describe the controller/presenter with a reference to the view. So, to create an instance of the controller inside the test code, we need the view as well. This still makes the development of unit tests difficult.

There is a turnaround to this problem, which is basically to add an interface between the controller and the view to break this dependency and abstract the view’s components. But the idea behind this solution increases the amount of code and does not imply in less complexity and clean organization. In most of the cases, this resolution is not worth the effort when there is a third option such as the Presentation Model pattern.

In this article I explain the Presentation Model pattern, its structure and layers.

Presentation Model is a design pattern used to build desktop GUIs with a clean separation of concerns. One of the most important advantages of this pattern is the easy creation of unit tests that can focus on the application logic without touching UI components. In fact, this is a goal that many other patterns have failed to accomplish. Read the advantages of the Presentation Model pattern for more details.

The first characteristic of the Presentation Model pattern that you have to understand is how its classes (often referred to as layers) are organized. Figure 1 shows its structure, which details the following classes: view, presentation model and service layer. Before explaining each of them, pay special attention to the references (arrows) and notice that the class that holds the state and logic of the GUI (presentation model class) does not have a reference to the view. What happens is exactly the opposite: the view that has a reference to this class.

Let’s understand the role of each of these classes in the pattern:

• View: Simple class that contains the UI components. The displayed data reflects the state kept by the Presentation Model class.
• Presentation Model: Class that holds the state of the GUI and its logic. The code operates on data and variables in memory and is unaware of the existence of UI components and presentation formats.
• Service Layer: Class that represents a channel between the Presentation Model and the outer world, where different types of service might exist (e.g., EJBs, databases, etc.). What lies beyond this layer is not seen by the Presentation Model class.

Figure 1: Three layers of the pattern

The Presentation Model class has no idea about views. It simply holds the state of the GUI and fires events when this state changes. Moreover, it is possible to attach more than one view to a presentation model instance, which leads to diferent visualizations of the same data.

The separation into decoupled layers and different responsibilities brings important advantages to the GUI implementation and maintenance. When we work this way, the layers become thinner and Ö consequently Ö more simple, which increases the understandability of the code. Besides that, the operations with models and business rules happen only in the presentation model layer, where the unit tests can reach efficiently.

The Presentation Model pattern applied without a framework requires some synchronization code between the layers (see the articles on the JGoodies Binding API).