PC SOFT

ONLINE HELP
FOR WINDEV, WEBDEV AND WINDEV MOBILE

Home | Sign in | English US
  • 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
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadApple WatchUniversal Windows 10 AppWindows Mobile
Others
Stored procedures
Overview
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. (It can be combined with a division of the access to data, in layers, that can be called DAL : Data Access Layer, and that separates the information in memory from the physical access to the database). It allows you to separate the code for interface management from the code that is using the business data.
This layered architecture of application and GUI simplifies the maintenance and evolution of projects.
Caution: This development mode is using the OOP: it requires a good knowledge of these concepts. This development mode is an advanced development mode.
WINDEV, via its RAD and examples, proposes a MVP that can be freely adapted according to your requirements and to your own architectural choices.
Principle
A MVP development model is divided into layers as follows:
MVP principle

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, Close, Info, Error, etc.
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> 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, 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.
Related Examples:
WD Discovering MVP - Part 1 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.
WD Discovering MVP - Part 2 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).
Minimum required version
  • Version 20
Comments
Click [Add] to post a comment