Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Further discussion on the Design principle of MV* (MVVM MVP MVC) pattern-Encapsulation and decoupling

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

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

Refine and add to: under the interface: restore the real MV* mode

The application of the graphical interface provides the user with a visual interface that provides data and information. User input behavior (keyboard, mouse, etc.) will execute some application logic, and application logic (application logic) may trigger certain business logic (business logic) to change the application data, which naturally requires synchronous changes in the user interface to provide the most accurate information.

In order to better manage the complexity of the application when developing the application, the application will be layered based on the idea of separation of responsibilities (Speration of Duties). When developing a graphical interface application, the administrative user interface layer is called View, and the data of the application is Model. (note that Model here refers to Domain Model, which abstracts the data of the problem to be solved, does not include the state of the application, and can be simply understood as an object). Model provides the interface for data operation and executes the corresponding business logic.

With the layering of View and Model, the question arises: how does View synchronize changes to Model, and how do View and Model glue together?

What problem does the MV* mode solve?

MV* realizes the decoupling of domain model data and UI layer.

MVC, MVP and MVVM have different ways to decouple them. From a historical point of view, MVC, MVP and MVVM are evolutionary relationships. However, in view of the scale of the project and the different ways to implement the model, different MV* models have their own advantages and disadvantages, so it is difficult to tell the good from the bad.

But the industry increasingly believes that MVVM is the best MV* model in the front-end domain. Angular and Vue are models of MVVM model.

Dependency relationship of MVC

MVC divides the application into View and Model layers, and adds an additional Controller layer, which is responsible for the cooperation between Model and View (routing, input preprocessing, etc.).

Model is mainly related to business data.

View is a visual representation of application data.

Controller manages the logic and coordination between Model and View in the application.

The user's input to View and other operations will not deal with the logic in the relevant modules of View, but these operations (so-called Pass Call) will be obtained by the Controller layer, and the data in these operations will be operated by the Controller layer through the application logic, and then the interface of the Model layer will be called to give the data to the Model layer. The Model layer performs operations related to the business logic and updates the data. Model and View are linked through the observer pattern, that is, View is the observer of Model, and when the Model data changes, it notifies the View layer to update the data.

Advantages of MVC

All the business logic is separated into Controller with a high degree of modularization. When the business logic changes, you don't need to change the View and Model, just change the Controller to another Controller (Swappable Controller).

Observer mode allows multiple views to be updated at the same time.

Shortcomings of MVC

Controller testing is difficult. Because view synchronization is performed by View itself, View can only be run in an environment with UI. When unit testing Controller without UI, the correctness of Controller business logic cannot be verified: when Controller updates Model, it cannot assert the update operation of View.

View cannot be componentized. View is strongly dependent on a specific Model, and it is difficult to extract this View as a reusable component of another application. Because the Domain Model of different programs is different.

MVP mode

Compared with MVC mode, MVP has obvious characteristics. The dependency between M and V in MVP is eliminated.

In MVC, M and V depend on each other through the observer mode. This dependency is transferred to the M and P layers in MVP. In this way, the P layer must notify the V layer to update the data through a certain mechanism. So layer V in MVP mode provides an interface for layer P to call. The P layer as the observer obtains the data change by reflecting the change to the V layer by calling the interface of the V layer.

In MVP:

The Model layer is still mainly related to business data. 、

View is still a visual representation of the application, but in MVP it is completely ignorant of domain data (the Model layer), and View is no longer responsible for the logic of synchronization, but by Presenter. There is both application logic and synchronization logic in Presenter. So the View layer is lighter than in MVC. However, View needs to provide an interface for Presenter to call

The Presenter layer is heavy, which calls not only the interface of Model, but also the interface of View. And you need to get Model's data updates as an observer.

The calling relationship of MVP (Passive View)

Advantages of MVP (Passive View)

Easy to test. Presenter does View through an interface, when unit testing Presenter is independent of the UI environment. You can Mock a View object, which only needs to implement the interface of View. Then the dependency is injected into Presenter, and the correctness of the Presenter application logic can be fully tested during the unit test. Here is a unit test sample of Presenter based on the above example.

View can be componentized. In MVP, View does not rely on Model. This allows View to be separated from specific business scenarios, and it can be said that View can be completely ignorant of the business. It only needs to provide a series of interfaces for upper-level operations. This allows for highly reusable View components.

MVP (Passive View) disadvantages

In addition to the application logic in Presenter, there are a large number of manual synchronization logic of View- > Model,Model- > View, which makes Presenter bulky and difficult to maintain.

MVP (Supervising Controller)

In Supervising Controller mode, Presenter will leave part of the simple synchronization logic to View to do, Presenter is only responsible for more complex, high-level UI operations, so it can be regarded as a Supervising Controller.

Because Supervising Controller is less used, MVVM can be seen as a special MVP (Passive View) pattern, or an improvement on the MVP pattern.

Dependence of MVVM

In Model-View-ViewModel mode, changes in data in the M layer are not notified to the V layer through the Observer mode (that is, there are no M and V dependencies), nor are the data passed to the V layer by calling the interface of the V layer through the VM layer (which means that the user code does not need to update the V layer manually). Instead, a special binder is implemented in the VM layer to bind data directly from the M layer to the V layer. In this way, the ViewModel layer knows the Model layer, and the View layer knows the ViewModel layer.

ViewModel acts as a data converter. It converts Model information into View information and passes commands from View to Model. Here, View can access ViewModel,ViewModel and Model.

The calling relationship of MVVM is the same as that of MVP. However, there will be something called Binder, or Data-binding engine, in ViewModel. The data synchronization between View and Model, which was previously entirely handled by Presenter, is handed over to Binder. You only need to declare in the template syntax of View which piece of data that is displayed on View is bound to Model. When ViewModel updates the Model pair, Binder automatically updates the data to View, and when the user operates on View (such as form input), Binder automatically updates the data to Model. This approach is called Two-way data-binding, bidirectional data binding. It can be understood simply and inappropriately as a template engine, but it will render in real time based on data changes.

MVVM automates the synchronization logic of View and Model. The View and Model synchronization that Presenter used to be responsible for is no longer operated manually, but is left to the Binder provided by the framework. You just need to tell Binder,View which part of the data you display corresponds to Model.

Advantages of MVVM

Bi-directional binding technology, when the Model changes, the View-Model will be updated automatically, and the View will change automatically. Very good to achieve data consistency, do not worry, in this piece of data in the module is this value, in the other is another value. So MVVM mode is sometimes called model-view-binder mode.

Improve maintainability. It solves the problem of a large number of manual View and Model synchronization in MVP, and provides a two-way binding mechanism. Improve the maintainability of the code.

Simplify testing. Because the synchronization logic is left to Binder, and View changes with Model at the same time, you only need to make sure that Model is correct and View is correct. The testing of View synchronous updates is greatly reduced.

Shortcomings of MVVM

An overly simple graphical interface is not suitable, or a knife to kill a chicken.

For large-scale graphics applications, there are more view states, and the cost of building and maintaining ViewModel will be high.

The declaration of data binding is written in the template of View, and there is no way to break the debug.

The model in a large module can also be very large, although it is easy to use and it is easy to ensure the consistency of the data. at that time, if you hold it for a long time, it will cost more memory if you don't release memory.

Two-way data binding is not conducive to code reuse. The most commonly used reuse in client-side development is View, but the two-way data binding technology allows you to bind a model in a View, and different modules have different model. Then you can't simply reuse View.

If there is any update, only in the original text: then talk about the design principle of MV* (MVVM MVP MVC) mode-encapsulation and decoupling, if there is something wrong, please leave a message.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report