Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to understand MVC and its variants". In daily operation, I believe many people have doubts about how to understand MVC and its variants. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand MVC and its variants"! Next, please follow the editor to study!

Creating maintainable applications has always been a real long-term challenge in building applications.

Not long ago, I worked for a company whose core business application was the SaaS platform, which has thousands of corporate customers. This vital application has been under development for three years, and the code file is a mix of HTML, CSS, business logic, and SQL. Sure enough, two years after its release, the company decided to rewrite the app completely. Although these situations happen from time to time, many of us now know that this is wrong and how to avoid it.

However, in the 1970s, mixed responsibilities were a common practice, and people were still looking for better solutions. As the complexity of the application increases, modifying the UI will inevitably lead to changes in business logic, which become more complex, time-consuming, and may cause more problems (because more code is modified).

Therefore, MVC arises at the historic moment, it puts forward the "separation of concerns" between the front-end and the back-end to solve the above problems.

1979-Model-View-Controller

In order to solve the above problems, Trygve Reenskaug proposed the MVC pattern in 1979 to separate concerns and separate UI from business logic. This model was then applied to the development of desktop graphical interfaces that have been around since 1973.

The MVC pattern splits the code into three conceptual units:

Model (model) representing business logic

View (View) that represents the UI control: buttons, text boxes, etc.

A Controller (controller) that coordinates between the view and the model, which means:

It decides which views to display and which data to display

It converts user actions (such as clicking buttons) into business logic.

A model can be a single object (rather boring) or a structure made up of objects. -- Trygve Reenskaug 1979, MVC

The original MVC pattern had some other important concepts to understand:

View uses Model data objects directly to display data

When Model changes, an event is triggered to update View immediately (remember, there was no HTTP in 1979)

Each View is usually associated with only one Controller

Each interface can contain multiple pairs of View and Controller

Each Controller can correspond to multiple View.

The HTTP request-response paradigm I am familiar with now does not use the original MVC style. This is because, according to the original assumption, the data flows from View to Controller, as I am familiar with, but on the other hand, the data flows directly from Model to View without going through Controller.

Moreover, in the current request-response paradigm, when the data in the database changes, the update of the display View in the browser is not triggered (although it can be implemented in Web Socket). To see the updated data, the user needs to initiate a new request, and the updated data is always returned through Controller.

1987x2000-PAC/Hierarchical Model-View-Controller

PAC, also known as HMVC, can lead to better modular splitting in the context of UI fragment control.

For example, we will find that part of View is used in the same format by some other View, or even reused directly in the same View. A practical example is a web page showing fragments of RSS subscriptions that can be reused by other pages.

If you use HMVC, the Controller that handles the master request forwards the subrequests to other Controller for these controls to render, and then merges them in the rendering of the main View.

I have encountered this situation several times myself in the context of the HTTP request / response paradigm, but I have found an easier way to have UI make an AJAX call to the Controller where the control can be rendered. While maintaining the advantage of modularity without increasing the complexity of nested Controller calls, another advantage is that these subrequests can use a cache like Varnish.

1996-Model-View-Presenter

The MVC pattern injected a shot in the arm into the programming paradigm at that time. However, as the complexity of the application increases, further decoupling is needed.

In 1996, Taligent, a subsidiary of IBM, exposed their MVC-based model, MVP. The idea is to separate Model's focus on UI more thoroughly:

View is passive and unaware of Model

Focus on lightweight Controller (Presenter), which do not contain any business logic, but simply invoke commands and / or query models to pass raw data to View

A change in data does not directly trigger an update of View: it always updates View through Presenter, and Presenter. This allows Controller (Presenter) to perform some additional logic related to presentation before updating the view. For example, update other data at the same time, which is related to the changed data in the database

Each View corresponds to a Presenter.

This is closer to the current request / response paradigm I've seen: data flows always go through Controller/Presenter. However, Presenter still does not actively update the view, and it always needs to execute a new request to make the changes visible.

Presenter in MVP is also called Supervisor Controller.

2005-Model-View-ViewModel

Due to the increasing complexity of applications, Microsoft WPF and Silverlight architect John Gossman proposed the MVVM pattern in 2005, which aims to further separate the UI design from the code and provide a data binding mechanism from the View to the data model.

[MVVM] is a variant of [MVC], designed for modern UI development platforms. In modern UI development, View is the responsibility of the designer rather than the traditional developer. [.] The tools, languages, and people who use UI to develop applications are very different from business logic and data backends. -- John Gossman 2005, Introduction to Model/View/ViewModel pattern

Controller was "replaced" by ViewModel:

[View] it is the responsibility of Controller in MVC to encode keyboard shortcuts and control its own interaction with input devices. (the change in Controller in modern GUI development is a long story. I think it just fades out of the developer's implementation. It exists all the time, and we don't need to think about it like we did in 1979. -- John Gossman 2005, Introduction to Model/View/ViewModel pattern

The idea behind MVVM is:

One-to-one correspondence between ViewModel and View

Transfer the logic in View to ViewModel to simplify View

The data used by View corresponds to the data in ViewModel one by one.

Bind the data in ViewModel to the data in View so that changes in the data in ViewModel are immediately reflected in the View.

Similar to the original MVC pattern, this approach does not work for the traditional request / response paradigm because ViewModel cannot actively update View (unless Web Socket is used), which MVVM requires. Also, in my experience, it is not a common practice for Controller to exactly match the properties of ViewModel with the data used by View.

Model-View-Presenter-ViewModel

When building cloud-native complex enterprise applications, I tend to properly design the UI structure of the application as M-V-P-VM, where View Model is the Presentation Model proposed by Martin Fowler in 2004.

Model

A set of classes that contain business logic and use cases.

View

A template that the template engine uses to generate HTML

ViewModel (also known as Presentation Model)

Receive (or extract) raw data from the query (or extract from the Model entity) and hold the data that will be used by the template. It also encapsulates complex presentation logic to simplify templates. I find it important to use ViewModel because we never want to use entities in templates. So that we can completely isolate View from Model:

Changes in Model (such as changes in entity structure) rise and affect ViewModel, but do not affect templates

Complex presentation logic is encapsulated in ViewModel, so it will not be leaked (for example, creating methods in business entities that are only related to presentation logic) into the domain

The dependencies of templates become clear because they must be set in ViewModel. For example, exposing dependencies can help us decide what should be loaded from the database first to avoid Number1 problems.

Presenter

Receive a HTTP request, trigger a command or query, generate a HTML using the data returned by the query, ViewModel, template, and template engine and return it to the client. All View interactions go through Presenter.

Here is a very simple example of what I have implemented:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.