Cheat Sheet on MV Patterns for Web Application Design

On the Internet you can find many different implementations and schemes, already scored, MVC patterns. In different books, I also met different schemes. This causes some confusion and comments to my previous article: " Implementing the MVC pattern using the example of creating a business card site in PHP " is a confirmation of this. In search of truth, I tried to put everything in its place ... I re-read some literature and articles on design patterns and wrote an addendum to the mentioned article. But I decided to post this add-on as a separate topic in the hope of a feedback. Under the cat you will find several frequently encountered MVC and MVP schemes describing the life cycle of the application, as well as a description of the less popular HMVC and MVVM patterns. Of course, some of the listed patterns are applicable not only to web applications, but in the article they are considered in this context.

MVC

The MVC (Model-View-Controller or Model-State-Behavior) template describes a simple way to build an application structure whose goal is to separate business logic from the user interface. As a result, the application is easier scaled, tested, maintained and, of course, implemented.


On request “MVC” on the Internet you can find many different schemes in which it is very easy to get confused. Let's try to put everything in its place. Consider scheme 1:

')
1. When a user visits a web resource, the initialization script creates an instance of the application and launches it for execution.
2. The front controller's index action is performed, which generates the main page view.
3. The view is displayed to the user.

The first three steps are a simple chain, without using a model. Next comes the sequence where the model is involved:

4. After the application receives a request from the user, an instance of the requested controller is created and the specified action is invoked.
5. In this action, the model methods that modify it are invoked.
6. The view is generated (or the view is notified of the model update).
7. The view requests the data to be displayed.
8. The model returns the requested data.
9. The view displays the results to the user.


There is also such a scheme - scheme 2:


1. The controller receives the following request from the user.
2. Further, depending on the internal logic:
2a. Formed by the presentation of a page.
2b. Or, methods of model are caused.
3. The model notifies the idea of ​​changes.
4. The view is updated (if a model was involved in the chain) and displayed to the user.


In some diagrams, you can see the arrow from the view to the controller. Consider this case - scheme 3:

1. The application receives another request from the user: it creates an instance of the requested controller and invokes the specified action.
2. In action, a view is generated containing some form of data entry.
3. The form view is displayed to the user.
4. After the user fills out the form and clicks on the “Submit” button, the same controller is invoked, which checks and processes the data received from the form and generates another view or updates the current one.

Step 4, in fact, is equivalent to another step 1, initializing a new cycle ... Therefore, in all schemes we can assume an implicit connection in the direction from the view to the controller.

MVP

And now we will look at the scheme of the pattern MVP (Model-View-Presenter) - scheme 4:

1. After the application receives a request from the user, the requested Presenter and the action is determined. The application creates an instance of this Presenter and runs the action method.
2. The action method may contain calls to the model, for example, reading information from the database.
   
3. The model returns data.
4. After this, the action forms a representation to which the data received from the model is transmitted.
5. The generated view is displayed to the user.

In addition to MVP, there are other MVC-derived patterns, such as MVVM and HMVC .

HMVC

The implementation of the HMVC pattern (Hierarchical Model View Controller - Hierarchical Model-Controller-View) is used in the Kohana web framework. Consider the key difference from MVC - scheme 5:


The application represents a hierarchy of mutually independent MVC triads. In this case, each triad can directly contact the controller of the other triad. This approach allows us to solve some problems of scalability of applications that have a classic MVC architecture, reduce the dependence between different parts of the application, and facilitate further support and reuse of code. You can read more about the advantages of this approach in the article " Scaling Web Applications Using HMVC ".

MVVM

MVC has taken root in web applications largely because it does an excellent job with a request-response script.
The main feature of this scenario is the short lifetime of the View. A request comes in, which is transmitted to the corresponding controller, it initiates some processes in the model, and then a View is created, which is simply filled with data from the model and transmitted to the client in the browser. All in one pass.

When Ajax and rich client-side applications ( RIAs ) appeared, it turned out that MVC is not very well suited for working with page or application areas, which led to several different models: Model View Presenter (MVP) and then Model View ViewModel ). If most of the patterns are more or less familiar with the MVC and MVP patterns, very few have heard of the latter.

MVVM was originally described for Silverlight and has advantages for complex interfaces with a specific logic that differs from application logic. MVVM is distinguished by a “closer” connection between the Model and the View via the View-Model layer, which synchronizes data both at the event on the Model side and on the View side.

In MVC, the logic is sewn into the Model, it can also be placed in the Controller, but this is rightly criticized (Stupid Fat Controller). In MVVM, on the contrary, the logic is placed in the “intermediate” layer of ViewModel. Consider the MVVM scheme - scheme 6:

You define the visible area of ​​the screen and specify the most general information about it, without knowing what content will be displayed at run time. For HTML, the MVVM schema is especially good thanks to the DOM , which, as you know, can easily hold data. Therefore, MVVM was successfully implemented in the KnockOut.JS framework. Initially, everything is simple. There is a data model provided by the server. There is a representation in the form of a DOM, in the form of markup. And there is a Model View (Model View, if you wish), which describes a change in the View, links the Model and the View, and synchronizes this connection.

It should be noted that MVC is often interpreted simply as a separation of the three levels of the application, and does not regulate the connection between them in any way. Therefore, quite often, there are diagrams (one of these was given above) in which the Model and the View are linked by arrows, although it is obvious that the useful properties of scalability are lost when using different Views and the hierarchy of the Controllers.

Conclusion

No need to try to answer the question of which of the above patterns is better, etc. ... you need to take out only the main idea - “divide and conquer”, because it is very important that the layers be as independent as possible and easily replaceable.