A MVP development model is divided into layers as follows:
The notion of VIEW
A VIEW represents the GUI part of the application. It corresponds to the user interface. A VIEW can be a window, a report, a Web page or a mobile window.
Some operations may require an interaction with the user (error display, confirmation, ...), these interactions must be performed by the VIEW.
- The VIEW knows the presenter.
- The VIEW can use the binding to retrieve the data to display from the PRESENTER layer, or to send the information typed or modified by the user.
- The VIEW has a specific process to perform the necessary updates ("Request for GUI update" process). This process is automatically called during the initialization, then upon request by the PRESENTER layer or by the MODEL layer (RequestUpdateUI).
The notion of PRESENTER layer
The PRESENTER layer is a class that performs the link between the VIEW and the MODEL. It organizes and formats the MODEL data that will be displayed in the VIEW. It groups the processes regarding the user actions.
The PRESENTER layer does not have access to the VIEW, which means that the the PRESENTER layer must not directly access the controls of the VIEW.
On the contrary, the PRESENTER layer can request from the VIEW to be updated (via RequestUpdateUI
The same PRESENTER class can be used by several VIEWs (for a window or a report displaying the data coming from the same MODEL, for example : list of customers).
Eazch VIEW (window, report) must own a distinct instance of PRESENTER class.
On the contrary, several PRESENTERS can share MODELE instances.
The PRESENTER layer contains data and decides which "data" will be displayed in the VIEW. For example, change the status of a control, change the color of a row in a Table control, ...
The user actions are moved into the methods of the PRESENTER class, that redirects them to the MODEL layer. The PRESENTER layer groups all the processes regarding the user actions. Therefore, the code is centralized and it can be shared between the different VIEWs.
On the other hand, the PRESENTER layer does not access the GUI, so no functions such as Open
Conversely, the VIEW knows the PRESENTER layer. The view can call its Methods, read its Properties and use the Binding. A VIEW has a single PRESENTER.
In summary, the view communicates with the PRESENTER layer:
- by calling the methods of the class.
- by writing or reading properties of the class.
- by using the DataBinding to link to the properties of the class.
The notion of MODEL layer
The MODEL layer contains the "Business" data of the application as well as the logic that is used to handle it. This layer includes a set of objects based on the classes representing the data to use. The logic (therefore the operations) that allows you to handle this data is represented by classes and methods.
The MODEL layer is independent of the PRESENTER and VIEW layers. The PRESENTER layer knows its MODEL layer but, on the contrary, the MODEL layer does not know the PRESENTER layer and even less the VIEW.
The data to display in the VIEW is contained in the MODEL layer.
However, in order to centralize the operations for data retrieval, we are going to favor the access to data by going via the PRESENTER layer rather than directly accessing the objects of the MODEL layer. The communication will be performed between the PRESENTER layer and the MODEL layer around the association of a class from the PRESENTER layer and a class from the MODEL layer (via the <Associated>
In summary, the PRESENTER layer communicates with the MODEL layer:
- by calling methods of the associated class
- by writing or reading properties of the associated classes
The notion of DB Access layer
The layer for accessing the Database data can include:
- a group of sets of procedures,
- a set of classes.
These sets or classes allow you to manage the reading and writing of data in the MODEL layer from and to the physical database.
The benefit of separating this layer is to be able to modify and evolve in a centralized way the logical structure of the data and the storage format (relational DB, SQL DB, XML files, Webservice, ...)
However, this layer can be included in the MODEL layer.
These choices go beyond the MVP.
The notion of Application layer
The Application layer is used to manage:
- the logic for the transition between VIEWs,
- information common to the application (for example, centralize the connection to a DB, ...),
- the business layer of the application.