Model View Presenter Design Pattern

Introduction

Model View Presenter is the new kid on the block in the Enterprise Architecture design patterns which has derived from the classic model-view-presenter.
 
In this article I will explain the principles of this design pattern.

The Model View Presenter pattern

When you design the architecture of an enterprise application, you can realize that there are logical common layers common to all the architecture decisions:

• User interface layer (UI controls, views and presentation logic)
• Application Layer (services, workflow orchestration)
• Domain Layer (business objects and services, domain model entities, business rules)
• Resource access layer (data access and persistent to database systems, logging, access to network resources, and composition with external services)
  
  Model View Presenter (MVP) design pattern is an evolution of the traditional Model View Controller (MVC) to improve the separation of concerns and facilitate the automatic unit testing.

The model layer is the composition of the application layer and domain layer. That is, when the view receives an action, then the action triggers a command to the application layer through the presenter layer. The application knows the business logic of the solution and how to communicate to the domain entities and business services in the domain layer.

The view layer is the user interface (using GUI controls and widgets) to gather and display data as well as to route user commands to the presenter layer to act upon the data. The view must be as passive as possible (made of interactive controls waiting for user actions), so it's so simple and logic-free. The only possible logic to include in this layer is data binding techniques and the validation using desktop techniques as well as client-side Web techniques such Jscript and jQuery.

The presenter layer acts upon the model and the view. That is, the only way for the communication between the view layer and model is through the presenter layer (there is no direct contact). This layer can use the classic controller to route the application from one view to another view (manage the navigation logic to all the views you can reach from a particular one) as well as to manage the complexities regarding the input and output data such as loading, transformations, etc. The controller object is centralized to hold the navigation rules and other features such as security and logging; therefore it must be created upon startup and is a global object. You can implement this global object following the Singleton design pattern. It's remarkable to remember that the Presenter is also responsible for the presentation navigation of the solution as well as the enabling or disabling subviews. A subview is essentially a part of the screen such as a panel or child windows. Finally, let's say that all the communication between the model, view and presenter objects is done through well established interfaces. The Figure 1 shows the reference model of the Model View Presenter design pattern. In this model the Presenter is merely a mediator between the View and the Model, and in this way the Presenter logic is inherently more testable. By defining a contract for the View (through the IView interface), you separate the UI elements from others in the solution, so the view can be replace with other view implementing the same contracts as well as we can create mockable views. The same Presenter can be shared between different solutions.



Figure 1

Conclusion

In this article, I've explained the principles of the Model View Presenter design pattern. Now you have insights to be applied to your architecture decisions.