MVVM and MVC understanding

MVVM and MVC understanding

The definition of MVVM

MVVM is short for model-view-viewModel. Model-view-viewmodel.

The model refers to the data passed by the back end. A view is the page you see. The core of the Viewmodel MVVM pattern is the bridge between the View and model.

It has two directions: one is to turn the model into a view, which is to turn the data passed by the back end into the page you see. This is done by data binding. The second is to transform the view into a model, that is, the page you see into data on the back end. This is done by DOM event listening. Both directions are implemented, which we call bi-directional data binding.

Summary: Views and models cannot communicate directly under the MVVM framework. They communicate through the ViewModel. The ViewModel usually implements an observer, and when the data changes, the ViewModel can listen for changes in the data and notify the corresponding view for automatic updates. And when the user manipulates the view, the ViewModel can also listen for changes in the view. It then notifies the data that it has changed, effectively enabling two-way binding of the data. And views and ViewModels in MVVM can communicate with each other. The FLOW chart of MVVM is as follows:

The definition of the MVC

MVC is short for Model-view-Controller. Model-view-controller.

M and V refer to the same meaning as M and V in MVVM. C, for Controller, is the page business logic.

The purpose of using MVC is to separate M and V code. MVC is one-way communication. So the View and the Model, they have to be connected by the Controller. The difference between MVC and MVVM is not that VM completely replaces C. Viewmodels exist to extract business logic from Controller, not to replace Controller. Other view operations and so on should still be implemented in Controller. In other words, MVVM enables reuse of business logic components. Since MVC emerged earlier, the front-end is not so mature, and a lot of business logic is also implemented in the back-end, so there is no REAL MVC pattern in the front-end. And we mention MVC again today, because of the arrival of the big front end, the emergence of the MVVM pattern framework, we need to understand how MVVM this design pattern evolved step by step.

Why MVVM?

The MVC architectural pattern is OK for simple applications and conforms to the layering idea of software architecture. But in fact, with the continuous development of H5, people more hope that the application developed with H5 can be as good as Native, or close to the experience effect of Native App, so the complexity of front-end application is different now. At this point, front-end development exposed three pain points:

• Developers call the same DOM API a lot in their code, which is cumbersome and redundant, making the code difficult to maintain.
• A large number of DOM operations degrade page rendering performance and slow loading speed, affecting user experience.
• When the Model changes frequently, developers need to actively update the View; When the Model changes due to user operations, developers also need to synchronize the changed data to the Model, which is not only tedious work, but also difficult to maintain complex and changeable data states.

In fact, jquery was originally designed to make it easier for the front end to manipulate the DOM, but it only solved the first problem. The other two problems have always been with the front end. The emergence of MVVM perfectly solves the above three problems.

MVVM is composed of Model, View and ViewModel. The Model layer represents the data Model, and the business logic of data modification and operation can be defined in the Model. A View represents the UI component that is responsible for converting the data Model into a UI presentation. A ViewModel is an object that synchronizes the View and Model.

In MVVM architecture, there is no direct connection between View and Model, but interaction through ViewModel. The interaction between Model and ViewModel is bidirectional, so the changes of View data are synchronized to Model. Changes to Model data are immediately reflected in the View.

The ViewModel connects the View layer with the Model layer through two-way data binding, and the synchronization between View and Model is completely automatic without human intervention, so developers only need to focus on business logic, do not need to manually manipulate DOM, do not need to pay attention to the synchronization of data state. Complex data state maintenance is managed entirely by MVVM.

Vue. Js under MVVM framework

Vue. Js can be said to be the best practice of MVVM architecture, focusing on the ViewModel in MVVM. It not only achieves two-way data binding, but also is a relatively lightweight JS library with simple API and easy to use. Here’s a quick look at some of the implementation details of vue.js on bidirectional binding:

• Vue.js uses getters and setters for Object.defineProperty, combined with observer mode, to implement data binding.

• When passing an ordinary Javascript Object to a Vue instance as its data option, Vue iterates through its properties, turning them into getters/setters with Object.defineProperty. Getters/setters are invisible to the user, but internally they let Vue track dependencies and notify changes when properties are accessed and modified.

• Observer ：Data listener, can monitor all the attributes of the data object, if there is any change can get the latest value and notify subscribers, internal useObject.definePropertythegetterandsetterTo implement the

Compile: An instruction parser, which scans and parses the instructions of each element node, replaces the data according to the instruction template, and binds the corresponding update function

Watcher: The subscriber, which acts as a bridge between Observer and Compile, can subscribe to and receive notification of each property change, executing the corresponding callback function of the directive binding

Dep: Message subscriber, which maintains an array to collect subscribers (Watcher). Data changes trigger notify, which calls the update method of the subscriber

As you can see from the figure, when new Vue() is executed, the Vue enters the initialization phase,

On the one hand, Vue iterates over properties in the data option and converts them into getters/setters using Object.defineProperty to listen for data changes.

On the other hand, Vue’s instruction compiler Compile scans and parses the instructions of the element node, initializes the view, and subscribes to Watcher to update the view, at which point Wather adds itself to the message subscriber (Dep), initialization complete.

When the data changes, setter methods in the Observer are fired, which immediately calls dep.notify (), and the Dep starts iterating through all the subscribers and calls the subscriber’s update method, which updates the view accordingly when notified.