Talking about using MVC pattern to develop _javascript technique of JavaScript program

With the increasing attention to the foreground development, the increasing proportion of client code today, how to apply the MVC pattern in JavaScript development, this problem seems to have been mentioned, so I have a rough talk about their own views.

The basic idea of the MVC pattern is to simplify the development by encapsulating a application into model, view and controller three parts to reduce coupling. This is a hollow, you can actually see 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 show you what animals you choose from the Drop-down menu "Selanimal" can echo back to the Web page. The above is not the application of any design patterns and ideas to write the code. If you were to apply the MVC pattern here, what would the code become?

<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 controller var Whatdoesanimaldo = {//select View Start:
  function () {This.view.start ();
  Set:function (animalname) {this.model.setAnimal (animalname) is mapped to the update on the model by mapping the user's actions;
},
}; Whatdoesanimaldo Data Model Whatdoesanimaldo.model = {//Animal data animaldictionary: {cat: "Meows", Fish: "s Wims ", Bird:" Flies "},//current animal, which is the application status Currentanimal:null,//data model is responsible for business logic and data storage setanimal:
    function (animalname) {this.currentanimal = This.animaldictionary[animalname]? animalname:null;
  This.onchange ();
  //And notify the view update to show Onchange:function () {whatDoesAnimalDo.view.update (); //You also need to respond to the view's query for the current state getanimalaction:function (){return this.currentanimal This.currentanimal + "" + This.animaldictionary[this.currentanimal]: "Wuff?";}; Whatdoesanimaldo View Whatdoesanimaldo.view = {//user input triggers onchange event start:function () {document.getElementById ('
  Selanimal '). onchange = This.onchange;
  //This event sends a user request to the Controller onchange:function () {Whatdoesanimaldo.set (document.getElementById (' Selanimal '). Value); The//view updates the displayed method, where the view queries the model for the current state and displays it to the user update:function () {document.getElementById (' Whatdoesthisanimaldo '). I
  nnerhtml = WhatDoesAnimalDo.model.getAnimalAction ();
}
};
Whatdoesanimaldo.start ();

 </script>

...... Suddenly the code became so exaggerated e ....
I have not yet realized the observer pattern in it ...
It's really not good.

This brings out the biggest criticism of the MVC pattern: Applying the MVC pattern in a simple system increases the complexity of the structure and reduces efficiency.

So I think in addition to a few JavaScript controls, such as Click-anywhere-to-edit datagrid/tree control, or fckeditor/ TinyMCE a rich text editor such as this one that supports custom plugin is ideal for applying MVC, and in most practical b/s systems, JavaScript development is enough to benefit you by following the factory pattern. This is due to the different nature of front-end development and backend development. If you apply the MVC pattern to a asp.net or JSP project, the SDK will more or less automatically generate some view and controller code. But JavaScript is not even a good SDK, although there are a lot of mature framework, but eventually will greatly increase the amount of development.--javascript

What is more troubling than the amount of development is the problem of efficiency. Communication between the three tiers is an additional overhead. For the server side, the overhead of these communications is almost negligible. But for a relatively inefficient language such as JavaScript, multiple calls and event listening can significantly degrade performance. Moreover, because of the closure characteristics of Javascrip, inadvertently to get out of memory leaks, this is authentic stealing chicken not eclipse the rice ...
Therefore, for JavaScript development, moderate development may be more important than applying the academic knowledge you have learned, after all, front-end development is based on solving practical problems, not for dazzle. Of course, dflying GG is called "refactoring is everywhere"-if you think your own code is becoming more and more messy, maintenance is more and more difficult, then you should consider the need to refactor with MVC ~

One extra word: Is it not necessary to use MVC for the entire front-end development? No no~ in fact, the whole front-end development is a large MVC structure AH--

Information in the model:html/xhtml
View:style Sheet
Controller:emascripts and so on script
This is not the ultimate goal of web standards ....

Therefore, it is always more important to grasp the structure of the entire front-end code than to use the design module in JavaScript development.

There are, however, some excellent MVC frameworks, a comparison between a Seattle hacker and a designer Gordon L. Hempton, and here we take a look at:

1. backbone.js--Advantages: Strong community, strong momentum; disadvantage: abstract weak, many functions need to be increased.
2. sproutcore--Benefits: Support for bindings, reliable community, a large number of features, disadvantages: Excessive specification, difficult and unwanted characteristics decoupling.
3. sammy.js--Benefits: Easy to learn, easier to integrate with existing server-side applications; disadvantages: too simple to apply to large applications.
4. spine.js--Advantages: lightweight, complete documentation; disadvantage: Its core concept "Spine" is an asynchronous user interface, which means that the ideal user interface will never clog, and this foundation is flawed.
5. cappuccino--Benefits: A large, thoughtful framework, a good community, a great inheritance model; disadvantages: Created by iOS developers, using JavaScript to simulate objective-c.
6. knockout.js--Benefits: Support for bindings, complete documentation and tutorials; disadvantages: Poor binding syntax, lack of unified view component hierarchy.
7. Javascript mvc--Advantages: a reliable community; disadvantage: A string based inheritance model is poor, and the controller and view relationships are too tight and the bindings are missing.
8. GWT (Google Web Toolkit)--Benefits: A comprehensive framework, a good community, a reliable java-based component inheritance model; Disadvantages: It may not withstand the test of time, in addition, Java's abstraction on the client is somewhat clumsy.
9. Google closure--Benefits: A good component-based UI composition system. Disadvantage: Lack of UI binding support. The
ember.js--benefits: A rich template system with composite views and UI bindings; disadvantage: Relatively new, the document is not complete.
One. angular.js--Advantages: Good consideration of template scope and controller design, with Dependency injection system, support rich UI binding syntax. Disadvantages: The module of the code is not strong, the view of modularity is not enough.
batman.js--Advantages: Clear code, binding, persistent method simple; Disadvantage: A single case controller is used.