What is the difference between using MVC and MVP
Drawing attention to the problems described in the article “ The MVC pattern is a dead end for application development? “I think that the MVC mechanism itself was not explained in sufficient detail. And for the coloring in this article I would like to highlight the MVP. I think it is important to understand the differences between MVC and MVP and the common points of these two paradigms.
To understand the difference, let's first take a look at the conditions in which MVC got accustomed and what advantages it gave to applications.
Let's get back to the past. In those days, when people did not know the words AJAX. At a time when programmers were afraid to use JavaScript in the browser and therefore, they overloaded the entire page.
')
Take a simple example. The user fills in the registration form and sends it to the server. The server checks the entered data, detects an error and sends the already filled-in form back to the user.
Sending these forms to the server, we, in fact, send an event with the data to a specific Controller. It performs certain actions on the data and gives control to the view. The view generates HTML and sends the result to the user.
What is the result? It turns out that the whole page in the browser and its View on the server are one large distributed visual component. It has events, it also has an interface and an implementation.
The controller receives events in a specific format, thus it is possible to send events to it from different Views that support this format. An example of such a form is the login form with a login and password. It can be located, for example, in the corner of all pages, or displayed as a whole on a separate page.
It is advantageous to use MVC where the redrawing of the entire component occurs every time an event occurs from the user.
MVP was coined a little under other conditions. When you build an application based on the component framework. There is no need to constantly re-create the View.
The task of the MVP is to also make Views re-usable. To do this, each View implements a specific interface and implements an event mechanism for feedback from Presenter. If you look at the same example with the login form, you can create two View, one in the corner of the application, the other in the main window and sign Presenter for events from both. From the incoming event, the Presenter will receive the sender and through the View interface will receive all the data sent by the user.
Summarizing, we can say that MVC and MVP paradigms are very similar to each other, but their use depends on the conditions of use. For MVC, this is where the View is updated every time for an event, and for MVP, when the View does not need to be re-created every time.
PS Because Initially, the title contained an intrigue, and the content of the article did not fully correspond to its purpose, the title and article were adjusted to more appropriate to each other.
To understand the difference, let's first take a look at the conditions in which MVC got accustomed and what advantages it gave to applications.
Let's get back to the past. In those days, when people did not know the words AJAX. At a time when programmers were afraid to use JavaScript in the browser and therefore, they overloaded the entire page.
')
Take a simple example. The user fills in the registration form and sends it to the server. The server checks the entered data, detects an error and sends the already filled-in form back to the user.
Sending these forms to the server, we, in fact, send an event with the data to a specific Controller. It performs certain actions on the data and gives control to the view. The view generates HTML and sends the result to the user.
What is the result? It turns out that the whole page in the browser and its View on the server are one large distributed visual component. It has events, it also has an interface and an implementation.
The controller receives events in a specific format, thus it is possible to send events to it from different Views that support this format. An example of such a form is the login form with a login and password. It can be located, for example, in the corner of all pages, or displayed as a whole on a separate page.
It is advantageous to use MVC where the redrawing of the entire component occurs every time an event occurs from the user.
MVP was coined a little under other conditions. When you build an application based on the component framework. There is no need to constantly re-create the View.
The task of the MVP is to also make Views re-usable. To do this, each View implements a specific interface and implements an event mechanism for feedback from Presenter. If you look at the same example with the login form, you can create two View, one in the corner of the application, the other in the main window and sign Presenter for events from both. From the incoming event, the Presenter will receive the sender and through the View interface will receive all the data sent by the user.
Summarizing, we can say that MVC and MVP paradigms are very similar to each other, but their use depends on the conditions of use. For MVC, this is where the View is updated every time for an event, and for MVP, when the View does not need to be re-created every time.
PS Because Initially, the title contained an intrigue, and the content of the article did not fully correspond to its purpose, the title and article were adjusted to more appropriate to each other.
Source: https://habr.com/ru/post/171925/
All Articles