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.