Talking about JavaScript program development using MVC mode, mvcjavascript

Talking about JavaScript program development using MVC mode, mvcjavascript

With the increasing importance of front-end development and the increasing proportion of client code, the question of how to apply the MVC pattern in javascript development seems to be mentioned all the time, so let me give you a rough idea here.

The basic concept of MVC mode is to reduce coupling and simplify development by encapsulating an application into model, view, and controller. This is very void. You can look at an example:

<select id="selAnimal">  <option value="cat">cat</option>  <option value="fish">fish</option>  <option value="bird">bird</option></select><p id="whatDoesThisAnimalDo"></p><script type="text/javascript">document.getElementById('selAnimal').onchange = function() {  var thisAnimalDoes;  switch ( this.value ) {    case 'cat':      thisAnimalDoes = "cat meows";      break;    case 'fish':      thisAnimalDoes = "fish swims";      break;    case 'bird':      thisAnimalDoes = "bird flies";      break;    default:      thisAnimalDoes = "wuff?";  }  document.getElementById('whatDoesThisAnimalDo').innerHTML = thisAnimalDoes;}</script>

This applet will display what the animal you selected from the drop-down menu "selAnimal" can do back to the webpage. The above is the code that has not been written using any design patterns and ideas. What if I want to apply the MVC mode here?

<Select id = "selAnimal"> <option value = "cat"> cat </option> <option value = "fish"> fish </option> <option value = "bird "> bird </option> </select> <p id =" whatDoesThisAnimalDo "> </p> <script type =" text/javascript "> // whatDoesAnimalDo is a controllervar whatDoesAnimalDo = {// select View start: function () {this. view. start () ;}, // map user operations to model updates. set: function (animalName) {this. model. setAnimal (animalName) ;},}; // whatD OesAnimalDo data modelwhatDoesAnimalDo. model = {// animalDictionary: {cat: "meows", fish: "swims", bird: "flies"}, // The current animal, that is, the application state currentAnimal: null, // The data model is responsible for the business logic and data storage setAnimal: function (animalName) {this. currentAnimal = this. animalDictionary [animalName]? AnimalName: null; this. onchange () ;}, // notify the view to update and display onchange: function () {whatDoesAnimalDo. view. update () ;}, // you also need to respond to the view's query of the Current Status getAnimalAction: function () {return this. currentAnimal? This. currentAnimal + "" + this. animalDictionary [this. currentAnimal]: "wuff? ";}}; // WhatDoesAnimalDo view whatDoesAnimalDo. view = {// onchange event triggered by user input start: function () {document. getElementById ('selanimal '). onchange = this. onchange;}, // The Event sends the user request to the Controller onchange: function () {whatDoesAnimalDo. set (document. getElementById ('selanimal '). value) ;}, // view update display method, where the View queries the current status of the model and displays it to the user update: function () {document. getElementById ('whatdoesthisanimaldo '). innerHTML = whatDoesAnimalDo. model. getAnimalAction () ;}}; whatDoesAnimalDo. start (); </script>

...... Suddenly the Code became exaggerated. e ....
-- Even the observer mode has not been implemented in it...
It's really bad.

 

This brings out the biggest criticism of the MVC pattern: the application of the MVC pattern in a simple system will increase the complexity of the structure and reduce the efficiency.

So I think that apart from a few javascript controls, such as click-anywhere-to-edit datagrid/tree control, or FckEditor/tinyMCE, a rich text editor that supports custom plugin, is very suitable for applications other than MVC. In most practical B/S systems, javascript development will benefit you a lot if you follow the factory model. This is due to the different nature of front-end development and back-end development. If the MVC mode is applied to ASP.net or JSP projects, the SDK will automatically generate some view and controller code. But javascript-javascript does not even have a good SDK. Although there are many mature frameworks, it will greatly increase the development volume.

Compared with the development volume, efficiency is even more troublesome. Communication between three layers is an additional expense. For the server, the overhead caused by these communications is almost negligible. However, for a relatively low-efficiency language such as javascript, a few more calls and event listening can clearly feel the performance decline. In addition, because of the closure feature of javascrip, memory leakage occurs accidentally. This is the result of authentic chicken stealing...
Therefore, for javascript development, moderate development may be more important than the academic knowledge you have learned about the application. After all, front-end development is based on solving practical problems, rather than to be skillful. Of course, there is a saying in Dflying gg that "refactoring is everywhere"-if you think your code is getting messy and maintenance becomes increasingly difficult, you should consider whether you should use MVC to reconstruct it ~

 

Let's try again: Isn't MVC unnecessary for the entire front-end development? No ~ In fact, the entire front-end development is a big MVC Architecture --

Model: Information in HTML/XHTML
View: Style sheet
Controller: EMAScripts and other scripts
Isn't that the ultimate goal of web standards ....

Therefore, it is always more important to grasp the entire front-end code structure than to overwrite the design model in javascript development!

However, there are also some excellent MVC frameworks. A hacker from Seattle compared with designer Gordon L. hemton. Let's take a look:

1. Backbone. js-advantages: a strong community, strong momentum; disadvantages: weak abstraction, many functions need to be increased.
2. SproutCore-advantages: Support for binding, reliable communities, and a large number of features; disadvantages: over-standardization, difficult to decouple from unwanted features.
3. Sammy. js-advantages: easy to learn, easier to integrate with existing server applications; disadvantages: too simple to be applied to large applications.
4. spine. js-advantages: lightweight, complete documentation; disadvantages: its core concept "spine" is an Asynchronous User interface, which means that the ideal user interface will never be congested, this foundation is flawed.
5. Cappuccino-advantages: large and well-thought-out frameworks, good communities, and great inheritance models. Disadvantages: created by iOS developers and simulated Objective-C using JavaScript.
6. Knockout. js-advantages: Support for binding, complete documents and tutorials; disadvantages: poor binding syntax and lack of a unified hierarchical relationship between view components.
7. Javascript MVC-advantages: reliable communities; disadvantages: the string-based inheritance model is poor, and the relationship between the Controller and the view is too dense and lack of binding.
8. GWT (Google Web Toolkit)-advantages: a comprehensive framework, a good community, and a reliable Java-based component inheritance model. Disadvantages: it may not be able to withstand the test of time. In addition, java's abstraction on the client is clumsy.
9. Google Closure-advantage: A component-based UI combination system. Disadvantage: lack of support for UI binding.
10. Ember. js-advantages: a rich template system with a composite view and UI binding; disadvantages: relatively new, incomplete documentation.
11. Angular. js-advantages: it has good considerations for the template scope and controller design, has a dependency injection system, and supports a wide range of UI binding syntaxes. Disadvantage: the code is not efficient, and the modular view is not enough.
12. Batman. js-advantages: the code is clear, and the binding and persistence methods are simple. Disadvantages: The Singleton controller is used.