MVC/MVP pattern

MVC


There are three components: the Model, View, and Controller The purpose of the MVC pattern is to decouple the user interface from the internal application state and the business logic that manages that state. To accomplish this, the MVC pattern relies heavily on events so that the interface between the three components are not tightly coupled. In fact, only one object, the Model, is usually physically shared between the View and the Controller. In order to maintain the highest degree of flexibility with the MVC pattern, there are some rules to follow:

1. The Model manages all state information
2. The Model notifies the View of state changes through events rather than direct calls
3. The View manages all user interface state and display information
4. The View only queries the Model for state information--it never changes the Model's state
5. The View responds to user gestures and informs the Controller of those gestures using events
6. The Controller responds to View events
7. The Controller queries the Model for state information
8. The Controller can change the Model state using methods exposed by the Model
9. The Controller often constructs the Model and the desired View
10. The Controller implements the business logic of the application with regards to responding to user gestures

Martin Flower's view:
* Make a strong separation between presentation (view & controller) and domain (model) - Separated Presentation.
* Divide GUI widgets into a controller (for reacting to user stimulus) and view (for displaying the state of the model). Controller and view should (mostly) not communicate directly but through the model.
* Have views (and controllers) observe the model to allow multiple widgets to update without needed to communicate directly - Observer Synchronization.

MVP

* View contains the Presenter instance (view "knows" presenter)
* Presenter is the only class knowing how to reach to model and retrieve the data needed for performing business logic
* Presenter talks to the View through the view interface (abstracted representation of the View without UI specific attributes)
* View doesn't know nothing about the Model

Advantage of MVP: dummy slave view (also called Passive View) make stub testing easier


MVC vs. MVP
A comparison is discussed here

MVP design pattern implementation has a view totally unaware of model. Presenter is the one exclusively communicating with the model and sending DTO (in case of Supervising controller) to model or performing direct manipulation with the view UI elements.

On the other hand, in MVC we have next two "read data" cases:

* a view reading data directly from model and perform "declarative data binding" of its controls or
* controller retrieving data from model, pass that context data to view while loading the appropriate view and view then binds to that sent context data

In most of the "update data" use cases we have a view sending updated context data to controller, where controller performs some validation and/or business logic and updates the model with that data.