Aliaksei Papou

Attracting your attention with the article ‘Is MVC Pattern a Dead End for Application Development? ’ I think I have not explained in enough detail what the mechanism of MVC itself that’s why I should shed light on the MVP as well. I believe it is quite important to understand the difference between MVC and MVP and the common elements of both paradigms. To figure out the difference let’s have a look at the conditions why MVC has been widely spread out and what benefits it’s provided for application development. Let’s come back to the past. At the times when AJAX statement still had been unknown. At the times when programmers were afraid of using JavaScript in browser and that’s why had to reload the whole page. Let’s take a simple example. A user fills out the registration form and sends it to the server. Server validates entered data, determines the errors and sends the form with the filled data back to the user. Sending data to the server, in fact, we send the event with the data to the particular controller. It performs some actions with the data and transfers the control to the View. View generates the result with the HTML and sends it back to the user. What happens? Apparently the whole browser page and its server representation are the one big and distributed visual component. It has events as well as interface and implementation. Controller receives events in particular format and that’s why it is possible to send events to it from different views supporting that format. As an example it can be a login form with login and password. It can be placed for instance in the corner of each page or to be displayed on a separate page as well. MVC is advantageous to use when components are redrawn on every event received from the user. MVP was invented on a bit different conditions - when you build the application based on component framework and there is no need to constantly recreate the View. The goal of MVP is to make Views reusable. For that every View implements particular interface and events mechanism to communicate with Presenter. If to take another look at the example with the same form of entrance to the system - now it is possible to create two views – one in the corner of the application and another one within the main window and to subscribe the Presenter to both. From received event Presenter can get a sender and all data sent by the user via View interface. As a conclusion it is possible to say that MVC and MVP paradigms are quite similar to each other but their usage depends on the number of conditions. For MVC when View is refreshed every time on a particular event and for MVP when it is not required to recreate View every time. Having said this I would like to say that to use MVP as well as MVC is not enough to build up agile and scalable applications since they lead to the same problem of tight coupling between modules and require completely new approach that was described in previous article .