Discussion on MVC mode for JavaScript program development

With the development of the front desk increasingly attention, the proportion of client code increasing today, how to apply MVC pattern in javascript development, this issue seems to be directly mentioned, so Here I briefly talk about 1 of their own views.

The basic idea of THE MVC pattern is to reduce coupling and simplify development by encapsulating one application into three parts: model, view and controller. That sounds hollow, but you can actually 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 small program will show you what an animal can do from the drop-down menu "selAnimal". This is code written without applying any design patterns or programming ideas. What would the code look like if you applied the MVC pattern 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 1 a controller
var whatDoesAnimalDo = {
  //  Select view 
  start: function() {
    this.view.start();
  },
  //  Map the user's actions to updates to the model 
  set: function(animalName) {
    this.model.setAnimal(animalName);
  },
};
// whatDoesAnimalDo The data of model
whatDoesAnimalDo.model = {
  // animal The data of 
  animalDictionary: {
    cat: "meows",
    fish: "swims",
    bird: "flies"
  },
  //  The current animal That's this right here application The state of the 
  currentAnimal: null,
  //  The data model is responsible for business logic and data storage 
  setAnimal: function(animalName) {
    this.currentAnimal = this.animalDictionary[animalName] ? animalName : null;
    this.onchange();
  },
  //  And notifies the view to update the display 
  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 The view of 
whatDoesAnimalDo.view = {
  //  User input trigger onchange The 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 will model Query the current status and display it to the user 
  update: function() {
    document.getElementById('whatDoesThisAnimalDo').innerHTML = whatDoesAnimalDo.model.getAnimalAction();
  }
};
whatDoesAnimalDo.start();
</script>

... All of a sudden the code gets really exaggerated e...
I haven't even implemented the observer mode in it yet...
It's too bad.

This brings up one of the biggest complaints of the MVC pattern: applying the MVC pattern to simple systems increases structural complexity and reduces efficiency.

So With the exception of a few javascript controls such as ES30en-ES31en-ES32en-ES33en datagrid/tree control, or FckEditor/tinyMCE rich text editors that support custom plugin that are ideal for MVC applications, in most practical B/S systems, javascript development is just as rewarding as following factory mode. This is due to the different nature of front-end development and back-end development. If you apply the MVC pattern in ASP.net or JSP projects, SDK will more or less automatically generate 1 view and controller code. But javascript -- javascript doesn't even have a usable SDK, and while there are plenty of mature framework, it will eventually increase development significantly.

Compared with the development volume, more troublesome is the problem of efficiency. Communication between the three layers is an additional overhead. On the server side, the overhead of these communications is negligible. But for a relatively inefficient language like javascript, the performance degradation would be noticeable with a few more calls and event interception. Also, due to the closure features of javascrip, 1 accidentally caused a memory leak, which is a real chicken steal...
So, for javascript development, moderation may be more important than applying what you've learned, since front-end development is based on solving real problems, not showing off. Of course, Dflying gg has a saying that "refactoring is everywhere" -- if your own code is getting messier and more difficult to maintain, you should consider using MVC to refactor 1

One extra note: does the entire front-end development need not use MVC? no no - The whole front-end development is a big MVC architecture

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

Therefore, mastering the structure of the entire front-end code is always more important than overusing design modules in javascript development!

There are, however, some excellent MVC frameworks out there that a hacker and designer in Seattle, Gordon L.Hempton, have compared. Here's a look:

1. Backbone.js -- Advantages: strong community, strong momentum; Cons: Weak abstraction, lots of features to add.
SproutCore -- Benefits: binding support, reliable community, lots of features; Cons: Over-specification, difficult to decouple from unwanted features.
Sammy.js -- Advantages: easy to learn and easier to integrate with existing server-side applications; Cons: Too simple to be used in large applications.
4. Spine.js -- Advantages: Lightweight, well-documented; Cons: Its core concept, "spine," is an asynchronous user interface, which means ideally the user interface will never jam, and this foundation is flawed.
5. Cappuccino -- Advantages: large well-thought-out framework, good community, great inheritance model; Disadvantages: Created by iOS developers, JavaScript is used to simulate Objective-ES112en.
Knockout. js -- Benefits: Binding support, complete documentation and tutorials; Disadvantages: poor binding syntax, lack of unity 1 view component hierarchy.
7. Javascript MVC -- Advantages: Reliable community; Cons: The string-based inheritance model is poor, and the controller is too tightly bound to the view.
8. GWT (Google Web Toolkit) -- Advantages: comprehensive framework, good community, reliable COMPONENT inheritance model based on Java; Cons: May not stand the test of time, plus the Java abstraction on the client side is a bit clunky.
Google Closure -- Pros: Nice component-based UI composite system. Cons: Lack of UI binding support.
10. Ember.js -- Advantages: Rich template system with composite view and UI binding; Cons: Relatively new, documentation incomplete.
Angular.js -- Advantages: good consideration for template scope and controller design, dependency injection system, rich UI binding syntax. Cons: The code is not modular and the view is not modular enough.
12. Batman.js -- Advantages: clear code, simple method of binding and persistence; Disadvantages: Singleton controller is used.