Mpvc Part 1 in front-end design mode

Mpvc is short for model partial-View Controller ).

Recently I saw the mvvm mode and situ zhengmeiThere are some new ideas about the aveon framework. Mvvm deficiencies are considered as follows:

• All templates need to be placed on the front end (maybe the back end needs another copy ?)
• Modeling is only required for display purposes. Even fields not involved in logical processing need to be modeled, which is quite troublesome.
• Different pages require different VMS, resulting in high maintenance costs.
• For multi-page applications, you still need to writeCodeTo controlProgramWork Logic

The biggest beauty is that the data model is automatically bound to the view display.

Let's leave the MVC pattern aside, and start with the following structure and workflow:

• For an unspecified web application, a page should be composed of several different blocks. Different blocks are divided by functional areas.
• Different pages are composed of different functional area blocks.
• Webpage applications use Ajax technology to update only a part of the page content in order to pursue user experience. This process can be abstracted as the view refresh, add, and delete of functional area blocks.

This code is usually written in simple application development:

 
$. Get ('/action_url ',Function(Result) {$ ('# Result_panel'). Innerhtml (result );});
 

Repeat this process when updating the view, and other problems may occur:

• $ ('# Result_panel') strongly binds the code logic to the DOM element. Because the uniqueness of the ID limits the code block, it can only be used in singleton mode.
• $ ('. Action-hook-class ') indicates that the global space is contaminated and unnecessary selector scanning is required on pages that do not need to start this feature, to enable or disable this feature, additional control switch logic is required.

Modular code writing can avoid these problems: $ ('. Result-panel', contextscope) or $ ('. Action-hook-class', contextscope) is much more friendly.