preface

This series started with preparing yourself for an interview. Later found more and more sorting, almost 120,000 characters, finally decided to share to everyone.

In order to share the sorting out, I spent a lot of time, at least three times as much time as ONLY myself. If you like, welcome to collect, follow me! Thank you very much!

The article links

  • Front – end interview check and fill gaps -(1) tremble and throttling
  • (2) Garbage collection mechanism
  • (3) Cross-domain and common solutions
  • (4) Front-end local storage
  • (5) Rendering mechanism and redraw and backflow
  • Front – end interview -(six) browser cache
  • (7) XSS attack and CSRF attack
  • (8) Front-end encryption
  • (9) HTTP and HTTPS
  • Check and fill gaps in front interview –(10) Front authentication
  • (11) Front-end software architecture pattern MVC/MVP/MVVM
  • (12) From the input URL to the page to see the whole process (including three handshake, four wave detailed explanation)
  • Front – end interview leak -(13) memory leak
  • Front – end interview omission and filling -(xiv) algorithm and sorting
  • (15) Event Loop

Collection of articles:

The Index (120,000 character collection) contains more than a dozen other articles in the series written so far. The following new value-added articles will not be added in each link, strongly suggest that the comments like, pay attention to the collection!!!! , thank you! ~

Follow-up Update Plan

Design pattern, front-end engineering, project process, deployment, closed loop, vUE often test knowledge and other contents will be added in the future. If you think the content is good, welcome to collect, follow me! Thank you very much!

Ask for an extrapolation

At present, I am also preparing for job-hopping. I hope you and HR sister can promote a reliable front-end position in Wuhan! Email :[email protected]. Thanks! ~

An overview of the

MVC, MVP, and MVVM are common software Architectural patterns that improve the organization of code by separating concerns. Different from Design patterns, which are abstract methods summarized to solve one kind of problem, an architectural Pattern often uses multiple Design patterns.

To understand MVC, MVP, and MVVM, you need to understand their similarities and differences. Different parts are C(Controller), P(Presenter), and VM(view-Model), while the same part is MV(model-view).

The MVC pattern

MVC pattern (Model-View-Controller) : It is a kind of software architecture pattern in software engineering. It divides the software system into three basic parts: Model, View and controller.

  • Model – The Model layer is used to encapsulate the data associated with the application’s business logic and how it is handled. Once the data changes, the model notifies the relevant views.
  • View – View, as the View layer, is mainly responsible for displaying data and responding to user operations.
  • Controller – The Controller is the link between the Model and the View, receiving user events from the View and passing them to the Model, while updating the View with the latest Model controls from the Model.

Data Relationship:

  • View accepts user interaction requests
  • The View forwards the request to the Controller
  • The Controller operates on the Model to update data
  • After the data is updated, the Model notifies the View to update the data changes. PS: There is also a View that acts as an Observer to listen for any updates in the Model. Once an update event is emitted, the View automatically triggers an update to show the latest Model status. This approach improves overall efficiency and simplifies Controller functionality, but also results in tight coupling between the View and the Model.
  • View updates the changed data

Method:

All modes of communication are one-way

Structure implementation:

  • View: Use the Composite mode
  • View and Controller: Use the Strategy mode
  • Model and View: Use the Observer pattern to synchronize information

Disadvantages:

  • View layer overweight: View is strongly dependent on Model and has direct access to Model. So it’s inevitable that the View also includes some business logic. As a result, the view is overweight and difficult to modify later, and the reuse degree is low.
  • The View layer is also tightly coupled to the Controller layer: The View layer and the Controller layer, although seemingly separate from each other, are closely connected. Often a View and a Controller are paired together and used as a component. Lack of decoupling.

The MVP pattern

MVP (Model-View-Presenter) is an improvement of MVC pattern. There’s one big difference between MVP and MVC: In MVP, views don’t use models directly. They communicate with each other through a Presenter (the Controller in MVC), and all interaction takes place inside the Presenter. In MVC, the View reads data directly from the Model instead of through the Controller.

  • The Model-Model layer is still focused on business-related data and corresponding methods of processing that data.
  • View-view is still responsible for the display, but the View in MVP does not directly use the Model
  • Presenters serve as the “middle man” between View and Model. The View in MVP does not directly use Model, but provides an interface for the Presenter to update Model and then update View through observer mode.

Data Relationship:

  • View receives user interaction requests
  • The View forwards the request to the Presenter
  • Presenter operates on Model to update data
  • Model notifies Presenter of data changes
  • Presenter updates View data

Method:

There is two-way communication between the parts

Structure implementation:

  • View: Use the Composite mode
  • View and Presenter: Use the Mediator mode
  • Model and Presenter: Synchronize information using Command mode

MVC and MVP relationship

  • MVP: a variant of the MVC pattern.
  • In project development, UI is easy to change, and is diverse, the same data will have N ways to display; The business logic is also relatively variable. In order to make the application more resilient, we want to separate the UI, the logic (UI logic and business logic), and the data, and MVP is a good choice.
  • A Presenter replaces a Controller. It does more work and is more complex than a Controller. The Presenter handles events and executes the corresponding logic that maps to the Model operation Model. The code that handles how the UI works is basically in a Presenter.
  • Models and views in MVC communicate using the Observer pattern; In MPV, Presenter and View communicate with each other using Mediator mode. The Presenter operation Model uses the Command mode. The basic design is the same as MVC: the Model stores the data, the View represents the Model, and the Presenter coordinates the communication between the two. In MVP, the View receives events and then passes them to the Presenter. It is up to the Presenter to handle the events.

MVP pros:

  • Model and View are completely separated, and modifications do not affect each other
  • Use it more efficiently because all logical interaction takes place in one place – inside the Presenter
  • A single Preseter can be used for multiple views without changing Presenter logic (since the View always changes more often than the Model).
  • Easier to test. By putting the logic in a Presenter, you can test the logic outside of the user interface (unit testing)

MVP cons:

  • In addition to business logic, there is a large number of View->Model, Model->View synchronization logic, resulting in a cumbersome Presenter, once the View needs to change, the Presenter also needs to change, it is difficult to maintain.

The MVVM pattern

MVVM is short for Model-view-ViewModel. Introduced by Microsoft and disseminated by Martin Fowler. In MVVM, there is no need for the Presenter to manually synchronize the View to the Model. the View is data-driven, and the View changes when the Model changes, and the View changes when the Model changes. In this way, the business process can only care about the flow of data, without directly dealing with the page. The ViewModel only cares about data and business processing, not how the View handles the data. In this case, both the View and the Model can be separated, and changes in either side do not necessarily require changes in the other, and some reusable logic can be put in a ViewModel. Let multiple views reuse the ViewModel.

  • The model-Model layer only cares about the data itself and does not care about any behavior (formatting the data is the responsibility of the View), which can be understood here as a jSON-like data object.
  • View-mvvm views declaratively render data into the DOM using template syntax. When the ViewModel updates the Model, it updates to the View via data binding.
  • ViewModel – Similar to Presenter. ViewModel handles declarations in the View layer. When data changes in the ViewModel, the View layer updates; In the case of bidirectional binding, the data in the ViewModel is automatically updated once the View operates on the bound data.

Data Relationship:

  • View receives user interaction requests
  • The View forwards the request to the ViewModel
  • ViewModel handles Model data updates
  • When the Model updates the data, it notifies the ViewModel that the data has changed
  • ViewModel updates View data

Method:

Two-way binding. Changes to View/Model are automatically reflected in the ViewModel and vice versa.

How to implement data binding:

  • Data Hijacking (Vue)
  • Publish-subscribe mode (Knockout, Backbone)
  • Dirty value checking (old Angular)

Use:

  • Compatible with the MVC/MVP framework you’re currently using.
  • Increase the testability of your application.
  • It works best with a binding mechanism.

The MVVM advantages:

The MVVM pattern, like the MVC pattern, aims to separate views and models. It has several advantages:

  • 1. Low coupling. Views can be changed and modified independently of the Model. A ViewModel can be bound to different “views”. The Model can be unchanged when the View changes, and the View can be unchanged when the Model changes.
  • 2. Reusability. You can put some view logic in a ViewModel and have many views reuse that view logic.
  • 3. Independent development. Developers can focus on business logic and data development (ViewModel), and designers can focus on page design, generating XML code.
  • 4. Testable. Interface elements are more difficult to test, and now tests can be written against viewModels.

The MVVM faults:

  • The classes will grow, the ViewModel will grow, and the complexity of the call will grow.

Thanks and Reference

  • A decade of CHANGE in GUI application architecture: MVC, MVP, MVVM, Unidirectional, Clean
  • 【 Framework 】 MVC, MVP, MVVM use relationship summary
  • Diagrams of MVC, MVP and MVVM
  • Brief analysis of MVC/MVP/MVVM model in front-end development