Model–view–presenter

Model-View -Presenter ( MVP abbreviation; approximately, model - view - presenter ' literally) is a design pattern in software development, which emerged from the Model-View- Controller (MVC). It describes a novel approach to completely separate the model (german model) and the view ( engl. view) from each other and connect to one presenter (English presenter ). In addition to a significantly improved testability is also the stricter separation of the individual components as opposed to MVC in the foreground.

For the first time used and called this design pattern was in the 1990s by IBM and Taligent. However, Martin Fowler formulated in 2004 model -view -presenter according to his understanding. His 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 ).

This MVP can develop its actual advantages over MVC, each interface (English interfaces) are used for model and view. The interfaces define the exact structure of both layers and the presenter only the interfaces associated with each other. This ensures the full exchange and reusability of the model and the view. As a result of the interchangeability of view, especially a double ( French for doppelganger ) can thus be used for the view to the functionality from the perspective of the surface with so-called unit testing (English unit tests) to check.

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

Supervising Controller

Supervising Controller (literally as " Supervising Control" ) is a design pattern that emerged from the original version of MVP and was defined by Martin Fowler. Here, the view inherits all the possible tasks for data synchronization, while the presenter takes care of all other processes between model and view. To simplify the synchronization possible, can be used on data bindings ( engl. data bindings ). In this case, the presenter provides information through classes that are the view and the model known. The presenter itself provides only for the transmission of the data objects from the model to the view. This eliminates additional synchronization overhead by the presenter, as the view synchronized independently on the data objects. The model can in turn also on the data objects to changes in the view data access.

Passive View

Passive View (literally as " Idle view ") is a design pattern that emerged from the original version of MVP and was defined by Martin Fowler. In contrast to the Supervising Controller does not connect via a data object between model and view. This contributes to the fact that the presenter must perform any data synchronization between the model and view itself. The result of this is that the view contains only simple logic to display and no logic to synchronize data. Thus, the source of the view is extremely simplified, as this is different with the Supervising Controller the case.

Differences

In the Passive View the testability improvement over the Supervising Controller, since only simple source code for input and output is available in the view. If the view in tests replaced by a mock object, including the source code is checked for synchronization in the presenter. It remains in this case, no significant logic more in the view. This therefore improves the testability of the presenter and model critical.

In contrast, the Supervising Controller offers the advantage of easier handling. By the data synchronization of data bindings between the model view and the synchronization overhead is reduced substantially, which makes a total of less source required as it is the case in the passive view.

577332
de