Theory of front-end MVC, MVP, MVVM think 2

The MVC design pattern considers the architecture and organization of the software from the point of view of code separation, originally originated from the Smalltalk language, and later in the Gof in-depth explanation;

The MVC architecture at Smalltalk has the following features:

M represents the source of the business data;

P presentation display by the view and controller at the same time maintenance, indispensable, for each model has a corresponding VC pair, so VC no real separation;

C Controller handles the input of the user and executes the corresponding business logic;

O OBSERVER pattern Observer mode is used, because whenever the model changes, the corresponding VC processing needs to be notified;

Observer pattern evolved into today's publish/subscribe model;

"Spaghetti" translates into spaghetti, which is used to tease out how to write code before using the MVC framework, which is characterized by poor readability, poor maintainability, and the idea of MVC and layering in front and back, with good maintainability and the responsibility of simply presenting the data at the front end , leading to more focus on the backend; but the era is changing rapidly, with the new forces of Google and Facebook hoping to outperform traditional software companies like IBM, presenting data in a better user experience (through graphs), leading to a gradual expansion of the responsibilities of the front-end, so complex business logic is involved, Enables new frameworks and development models to be updated quickly.

Review the typical MVC framework with the following features:

M logic Independent, do not involve VC, when the data changes, in a publish way to notify each observer, the realization and VC separation;

The display of the V view replaces the original string stitching method with the template, and the binding of the triggering event is done by the controller, which is not good, it is a disadvantage (because it binds the view association to the controller, the separation is unrealistic), But it is indeed what the current framework backbone can offer,

Excerpt from: Wonder where User-interaction comes into play. When users click on any elements within the view, it's not the view's responsibility to know-to-do next. It relies on a controller to make this decision for it. In our sample implementation, this is achieved by adding a event listener to photoEl which would delegate handling The Click Behaviour the controller, passing the model information along with it ' s needed.

C acts as a mediator of the MV, when v changes, by C to notify M to change; re-render v when M is changed;

According to the first blog post introduction, backbone is not strictly the MVC architecture, but belongs to the mv* family, because VC does not separate, personal angle to consider, backbone framework intrusion is too strong, interfered with the normal execution process, the user spends a lot of time in the internal execution logic, easy to learn, Easy to learn and difficult to change;

See blog post MVP Introduction, feel the text of the confused, or did not see the difference between C and P, perhaps the brain is full of too many backbone logic, so can only be summed up, the MVP model is literally p instead of C, the actual thought is a progress:

1. MVP written components, can be tested strong, can be used for the function of components to do unit testing, improve the reusability;

2. The use of external services for components is limited to the P-level, without the need to focus on V, and the application based on this development is out of focus and dependence on V;

3. Enterprise-class software can be used for rapid development of such basic components;

For the front-end development, the pure MVC development is difficult, the difficulty is mainly because the non-business logic that listens and handles the view is put there more suitable, if put in C, then VC does not separate; if placed in v,v not very good implementation (not heard of particularly mature such framework) Backbone-based MVC is more of a VC mix, resulting in C being kidnapped by V (although V is often fixed and does not change often);

Based on the MVP idea of the class library, such as the Dojo Framework base Class library, users often only need to focus on the use of which can satisfy the business function of the component, not how the component is used; TheMVP component will also have its own m and V, but M is not related to the business m, because the purpose of the MVP is reusable, In the case of MVC, M is fixed on some kind of business m;

　　

Reference:

1. Understanding MVC and MVP http://addyosmani.com/blog/ understanding-mvc-and-mvp-for-javascript-and-backbone-developers/

Theory of front-end MVC, MVP, MVVM think 2