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

This article will explain in detail what the significance of the front-end MV* framework is, the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

People often question what is the point of doing MV* at the front end. Some people also ask: what is the difference between the MV* framework represented by AngularJS,Knockout,BackBone and the framework like jQuery? I use jQuery well, why is it necessary to introduce this framework again?

Before you answer these questions, you need to sort out some history. when did the front end have a framework?

In the early days, the front end is relatively simple, basically taking the page as the unit of work, the content is mainly browsing, and occasionally there are simple form operations. During this period, there is only a little JavaScript logic on each interface, and basically there is no need for a framework. With the emergence of AJAX, the rise of Web2.0, people can do more complex things on the page, and then the front-end framework really appeared, represented by jQuery, for the interface common DOM operations, remote requests, data processing and so on have been encapsulated, there are also focused on data processing Underscore, strictly speaking, these can not be regarded as a framework, but a library.

There are some differences between a library and a framework: a library is a tool that I provide, and you don't have to use it, even if you use it, it doesn't affect your own code structure. The framework is oriented to an area and provides a set of solutions, and if you use me, you have to do things my way. According to this definition, jQuery and Underscore are only libraries, while ExtJS and dojo are frameworks.

Why is the MV* framework emerging? With the emergence of it, with the gradual development of some Web products to the application direction, we have encountered the same problem in the field of Cmax S: due to the enhancement of the front-end function and the expansion of the code, we have to do the "front-end architecture".

Many people who do back-end development disdain the front-end architecture, thinking that the front-end is just a very thin layer of things, so why do they do the architecture? What, we should not only engage in architecture, but also MVC? In the MVC of Java Struts, the whole front end can only be regarded as View. Do you have to divide the model and controller and other things in this View? Most of them disdain this, but as the complexity of the front end of Web increases, many places are no longer essentially different from the client.

JQuery's way of thinking is to focus on DOM operation.

The way of thinking of the MV* framework is that it is model-centric and DOM operations are just attachments.

So back to that question, jQuery meets your business needs, so why do you need to introduce the MV* framework?

This depends on the product type, if it is a page product, most of them do not need it very much, because the JavaScript code in the page handles the interaction far more than the processing model, but if it is an application software product, it is too necessary.

Companies that have been doing software in an industry for a long time generally precipitate some business components, mainly reflected in data models, business rules and business processes. These components basically exist in the back end, and there are few corresponding organizations in the front end. In past experience, they have done MVC and tried to do some interface components, but the practice is relatively outdated, such as using JSF or GWT.

What is the problem with JSF? Its problem is not that the interface is mixed with logic, the so-called vertical split components, Polymer this pure front-end framework is also split, its problem is that the component generation and rendering are not in the same place. Therefore, the position of the logic code is very awkward, if the interface is simple, it will be very troublesome, that is, a lot of front-end logic code needs to be generated through the back end.

GWT is relatively better in this way, but its problem is that it leaves too little room for UI adjustment and lacks flexibility.

This kind of component-based approach based on a certain server-side technology has some limitations, such as it greatly limits the performance of the front end, which might have been good earlier, but now with the development of the times, users have higher and higher requirements for front-end user experience, which requires us to put a large part of our energy back to the front end. Another problem with solutions such as JSF is that it is bound to a certain server environment, so it is difficult to switch to another backend. If you want to develop in Hybird, it is almost impossible to reuse some front-end logic.

So, let's look at the pure front-end framework and see how they solve these problems. Take Google as an example, it has launched two frameworks, Polymer and Angular, and they are in the stage of parallel development. There is still a big difference between the two concepts, which brings confusion to many people.

The way Polymer splits components is a bit similar to JSF. It has a lot to do with Shadow DOM and Element in the HTML5 standard. This way of dividing components is very intuitive. Each component is end-to-end, including UI and logic, and can be used directly on an interface. This method is easily accepted by business developers, but the timing is difficult to deal with.

For example, there are two components, each containing a drop-down box with data linkage, because they are in two different components, the linkage processing code is very difficult to write, considering the characteristics of the component, try to hide your own internal implementation, so it is necessary to go around one layer to get an element inside the component from the outside, while the component cannot rely on other external things, so you can only achieve it through events. Where this linkage code should be written is also a big problem. Our example is so simple that we have to go around in such a big circle to ensure the timing. If the scene is complex, it is very difficult to control.

If the same component is reused many times in an interface, it is difficult to ensure data consistency. Imagine that there are two same drop-down boxes in an interface, which are in different components, and the data of both need to be loaded separately. This process is wasteful. What is more serious is that if the data corresponding to this drop-down box is updated, it is difficult to update each instance. This process is very troublesome.

Unlike the way the Angular framework handles problems, it is horizontally layered, and all this data access logic is completely separated from UI, so you can easily write this logic code, so that the above-mentioned end-to-end components are completely degenerated and only the interface is displayed.

Take a look at the two problems just encountered, *. The model code is divided by business domain, and the acquired data is placed in two different arrays, and then associated with UI through two-way binding. If the item selected in the last drop-down box of UI changes, you only need to monitor this value item, and then update the value list of another drop-down box. There is no need to beat around the bush. Even if the two are in different models, we can use a square similar to the back end and use mechanisms such as event bus to complete the communication.

The second is even more simple, the reuse component is actually only UI, that is to say, only UI is multi-instance, and there is only one model, for example, the tree structure of a region, even if there are both maintenance and use functions on an interface, the same model can be shared. When the data is updated on the maintenance side, it will be fed back to the model in real time. Then the model is synchronized to the user on the interface by two-way binding, and the whole process is clear and controllable.

In terms of collaborative relationships, the responsibilities of each member of many front-end development teams are not very clear, and with the front-end MV* framework, this situation will be greatly improved. The idea of the MV* framework is to layer the front end according to responsibilities, each layer is relatively independent, has its own value, but also has its own room to play.

Why do most of the students who do front-end development of the Internet do not feel the importance of the MV* framework, because in this collaboration system, this part of Model is not complex enough, in the traditional software domain, the part of Model is the most, and the part of View is relatively less, while in the field of the Internet, it is basically the opposite, so Model this piece is reduced to an additional, if mainly in the operation of View and Controller, then of course frameworks such as jQuery are easier to use.

Therefore, we often see students with Internet products talking about front-end MVC, but when giving examples, they are relatively far-fetched. Very often, the Model they put forward is not a real Model, but some auxiliary models in the process of operating View. The real Model runs through the front and rear.

In the final analysis, the front-end MV* framework brings a whole set of workflow changes, and the back-end engineers can also write the front-end model code to completely connect it with the back-end. The interaction engineer handles the interaction between the UI and the model, and the UI staff can focus on and without barriers to deal with the HTML source code and provide them to the interaction engineers in the form of interface templates. This whole set of cooperation mechanism can greatly improve the development efficiency of Bhand S architecture system. If there is a peripheral management and control platform, production efficiency will really step into the stage of industrialization.

At this stage, what is the way out for front-end developers? I think there are two kinds. Compare with the clothing industry, if what you want is ordinary, use industrial means to mass production, use MV* framework, do a good job of framework and component reuse, do it quickly, do not pay much attention to details. If you want something better and distinctive, you need famous designers, handmade, very exquisite, high-end and high-end. Therefore, this represents the two development directions of front-end development.

On the meaning of the front-end MV* framework is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.