|
|
|
|
|
- Overview
- Principle
- The notion of VIEW
- The notion of PRESENTER layer
- The notion of MODEL layer
- The notion of DB Access layer
- The notion of Application layer
MVP Presentation: Model - View - Presenter
MVP is the acronym for MODEL - VIEW - PRESENTER. It is a "Design Pattern" that proposes to divide and structure the architecture of user interfaces into layers. (This can be combined with a data access layer, also known as DAL: Data Access Layer, which separates in-memory information from physical access to the database).. It allows you to separate the UI management code from the code that uses business data. This layered architecture of application and UI simplifies the maintenance and evolution of projects. Caution: This development mode uses OOP: it's mandatory to master its concepts.. This development mode is an advanced development mode. WINDEV and WINDEV Mobile, via their RAD and examples, provide an MVP that can be freely adapted to your needs and own architectural choices.
A MVP development model is divided into layers as follows: The notion of VIEW A VIEW represents the UI part of the application. It corresponds to the user interface (UI). 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 event to perform the necessary updates ("Request for refreshing the display" event). This event is automatically called during initialization, then upon request by the PRESENTER layer or by the MODEL layer (RequestRefreshUI).
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 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 RequestRefreshUI). The same PRESENTATION layer can be used by several VIEWS (e.g., a window or report displaying data from the same MODEL, such as a customer list).. 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/events regarding 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 UI, so Open, Close, Info, Error, etc. are not available. 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 rules that are 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> attribute). 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, web service, ...). 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, etc.),
- the business layer of the application.
Related Examples:
|
Training (WINDEV): WD Discovering MVP - Part 1
[ + ] This educational example explains how to implement an MVP architecture (Model View Presenter) in a project. This example is simplified in order easily understand the concepts of this architecture.
|
|
Training (WINDEV): WD Discovering MVP - Part 2
[ + ] This training example explains how to implement an MVP architecture (Model View Presenter) in a project for a simple analysis (Customer - Order - Order line - Product). Several types of views (as well as their presentation) are proposed: - table (with addition, modification, deletion and print), - form, - search (with filter).
|
|
Cross-platform examples (WINDEV Mobile): WM Discover MVP
[ + ] This example shows the implementation of an MVP (Model View Presenter) architecture in a project. This example has been simplified to better explain the concepts of this architecture.
|
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|