Model View Presenter

from Wikipedia, the free encyclopedia
The presenter contains the logic of the application. It is the link between the model and the view.

Model View Presenter (abbreviation MVP ; literally 'model view presenter') is a design pattern in software development that emerged from the Model View Controller (MVC). It describes a novel approach to the model (engl. Model ) and the view (engl. View ) complete each other to separate and one presenter (engl. Presenter ) to be connected. In addition to significantly improved testability, the focus is also on the stricter separation of the individual components in contrast to MVC.

This design pattern was first used and named in the 1990s by IBM and Taligent . Martin Fowler , however, formulated model-view-presenter in 2004 according to his understanding. Its definition is crucial today.

definition

MVP is based MVC as well as on three components: the model ( model ), the view ( view ) and the presenter ( presenter ).

Model
The model represents the logic of the view . This can also be the business logic. However, all functionality must be accessible via the model in order to operate the view . The model is controlled solely by the presenter . The model itself knows neither the view nor the presenter .
View
The view does not contain any controlling logic and is only responsible for the representation and the inputs and outputs. She does not have access to the functionality of the presenter or to the model . All control of the view is done by the presenter .
Presenter
The presenter is the link between the model and the view . It controls the logical processes between the other two layers and ensures that the view can fulfill its functionality.

So MVP can develop its actual advantages over MVC, are for model and view each interface (English, interfaces ) are used. The interfaces define the exact structure of both layers and the presenter merely links the interfaces with one another. This ensures that the model and the view can be completely exchanged and recycled . As a result of the interchangeability of view especially one can thus double ( French for doppelganger ) for the view of use to the functionality from the perspective of the surface with so-called unit tests (English, unit tests ) to test.

In 2006, Martin Fowler decided, based on findings from the practical application of MVP, to split the original design pattern into two differentiated patterns: Supervising Controller and Passive View . Both patterns differ in terms of their testability and their handling.

Supervising controller

Supervising Controller (literally "Monitoring Control") is a design pattern that emerged from the original MVP variant and was defined by Martin Fowler. The view takes onall data synchronization tasks as far as possible, while the presenter takes care of all other processes between the model and view . To simplify the synchronization possible, can be applied to data bindings (Engl. Data bindings to resort). The presenter providesdata about classes that are known to the view and the model . The presenter himself only takes care of the transfer of the data objects from the model to the view . This eliminates the need for further synchronization work by the presenter , as the view is automatically synchronized via the data objects. Forits part, the model can alsoaccess data that has changedwithin the view via the data objects.

Passive view

Passive View (literally “inactive view”) is a design pattern that emerged from the original MVP variant and was defined by Martin Fowler. In contrast to the supervising controller, there is no connection via a data object between the model and the view . This contributes to the fact that the presenter has to carry outany data synchronization between the model and the view himself. The result is that the view contains only the simplest logic for display and no logic for synchronizing data. Thisgreatly simplifiesthe view's source code, unlike the Supervising Controller .

differences

In the Passive View , the testability is improved compared to the Supervising Controller , since only the simplest source code for input and output is available in the view . If the view is replaced by a mock object during tests , the source text for synchronization in the presenter is also checked. In this case, there is no longer any logic worth mentioning in the view . This significantly improves the testability of the presenter and the model .

In contrast, the supervising controller offers the advantage of simplified handling. The synchronization of data via data links between the model and the view significantly reduces the synchronization effort, which in total requires less source text than is the case with the passive view .

Web links

Individual evidence

  1. Retirement note for Model View Presenter Pattern (English)