隨著前臺(tái)開發(fā)日益受到重視，客戶端代碼比重日益增加的今天，如何在javascript開發(fā)里應(yīng)用MVC模式，這個(gè)問題似乎會(huì)一直被提到，所以偶在這里粗略的談一下自己的看法吧。

MVC模式的基本理念，是通過把一個(gè)application封裝成model, view和controller三個(gè)部分達(dá)到降低耦合，簡化開發(fā)的目的。這么說很空洞，大家可以實(shí)際看個(gè)例子：

<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>

這個(gè)小程序會(huì)把你從下拉菜單"selAnimal"中選擇的動(dòng)物能做什么事回顯到網(wǎng)頁上。以上是沒有應(yīng)用任何設(shè)計(jì)模式和編成思想寫出的代碼。如果要在這里應(yīng)用MVC模式，代碼又會(huì)變成怎樣的呢？

<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 就是一個(gè)controller
var whatDoesAnimalDo = {
  // 選擇視圖
  start: function() {
    this.view.start();
  },
  // 將用戶的操作映射到模型的更新上
  set: function(animalName) {
    this.model.setAnimal(animalName);
  },
};
// whatDoesAnimalDo的數(shù)據(jù)model
whatDoesAnimalDo.model = {
  // animal的數(shù)據(jù)
  animalDictionary: {
    cat: "meows",
    fish: "swims",
    bird: "flies"
  },
  // 當(dāng)前的animal，也就是這個(gè)application的狀態(tài)
  currentAnimal: null,
  // 數(shù)據(jù)模型負(fù)責(zé)業(yè)務(wù)邏輯和數(shù)據(jù)存儲(chǔ)
  setAnimal: function(animalName) {
    this.currentAnimal = this.animalDictionary[animalName] ? animalName : null;
    this.onchange();
  },
  // 并且通知視圖更新顯示
  onchange: function() {
    whatDoesAnimalDo.view.update();
  },
  // 還需要響應(yīng)視圖對(duì)當(dāng)前狀態(tài)的查詢
  getAnimalAction: function() {
    return this.currentAnimal ? this.currentAnimal + " " + this.animalDictionary[this.currentAnimal] : "wuff?";
  }
};
// whatDoesAnimalDo的視圖
whatDoesAnimalDo.view = {
  // 用戶輸入觸發(fā)onchange事件
  start: function() {
    document.getElementById('selAnimal').onchange = this.onchange;
  },
  // 該事件將用戶請(qǐng)求發(fā)送給控制器
  onchange: function() {
    whatDoesAnimalDo.set(document.getElementById('selAnimal').value);
  },
  // 視圖更新顯示的方法，其中視圖會(huì)向model查詢當(dāng)前的狀態(tài)，并將其顯示給用戶
  update: function() {
    document.getElementById('whatDoesThisAnimalDo').innerHTML = whatDoesAnimalDo.model.getAnimalAction();
  }
};
whatDoesAnimalDo.start();
</script>

……突然一下代碼變得好夸張e....
——偶都還沒有在里面實(shí)現(xiàn)觀察者模式呢...
實(shí)在太不良好了。

這樣就帶出了MVC模式最大的詬病：在簡單的系統(tǒng)中應(yīng)用MVC模式，會(huì)增加結(jié)構(gòu)的復(fù)雜性，并且降低效率。

所以偶覺得除了少數(shù)javascript控件，比如click-anywhere-to-edit datagrid/tree control, 或者FckEditor/tinyMCE這樣的支持自定義plugin的富文本編輯器非常適合應(yīng)用MVC之外，在大多數(shù)的實(shí)用B/S系統(tǒng)中，javascript開發(fā)只要遵循工廠模式就足夠讓你受益匪淺了。這是由于前端開發(fā)和后段開發(fā)的性質(zhì)不同引起的。如果在ASP.net或者JSP項(xiàng)目中應(yīng)用MVC模式，SDK或多或少會(huì)自動(dòng)生成一些view和controller的代碼。但是javascript呢——javascript甚至連個(gè)好用的SDK都沒有，雖然有不少成熟的framework，但最終還是會(huì)大大增加開發(fā)量。

與開發(fā)量相比，更加令人頭疼的是效率的問題。三層之間的相互通信都是額外的開銷。對(duì)于服務(wù)器端，這些通信造成的開銷幾乎可以忽略不計(jì)。但對(duì)于javascript這樣相對(duì)低效率的語言，多幾重調(diào)用和事件偵聽就能明顯感覺到性能的下降了。而且，因?yàn)閖avascrip的閉包特性，一不小心就搞出內(nèi)存泄漏，這可是正宗的偷雞不成蝕把米了...
所以，對(duì)于javascript開發(fā)，適度開發(fā)可能比應(yīng)用你所學(xué)到的學(xué)術(shù)知識(shí)更重要，畢竟前端開發(fā)是以解決實(shí)際問題為基礎(chǔ)，而不是為了炫技。當(dāng)然，Dflying gg有句話叫“重構(gòu)無處不在”——如果你覺得你自己的代碼越來越亂，維護(hù)起來越來越困難，那么，你就該考慮是不是該用MVC重構(gòu)一下了~

再額外的說一句：是不是整個(gè)前端開發(fā)就不必使用MVC了呢？no no~ 其實(shí)整個(gè)前端開發(fā)就是一個(gè)大大的MVC架構(gòu)啊——

Model: HTML/XHTML中的信息
View: Style sheet
Controller: EMAScripts等等腳本
這不正是web標(biāo)準(zhǔn)的最終目的么....

所以，把握好整個(gè)前端代碼的結(jié)構(gòu)，永遠(yuǎn)比在javascript開發(fā)中過量應(yīng)用設(shè)計(jì)模重要的多！

不過，也有一些優(yōu)秀的MVC框架，對(duì)此西雅圖的一位黑客和設(shè)計(jì)師Gordon L. Hempton做了一下對(duì)比，這里我們拉過來看一下：

1. Backbone.js——優(yōu)點(diǎn)：強(qiáng)大的社區(qū)，強(qiáng)勁的勢(shì)頭；缺點(diǎn)：抽象較弱，很多功能亟待增加。
2. SproutCore——優(yōu)點(diǎn)：對(duì)綁定的支持，可靠的社區(qū)，大量特性；缺點(diǎn)：過度規(guī)范，難以和不需要的特性解耦。
3. Sammy.js——優(yōu)點(diǎn)：易于學(xué)習(xí)，更容易和現(xiàn)存的服務(wù)端應(yīng)用程序整合；缺點(diǎn)：過于簡單，無法應(yīng)用于大型應(yīng)用程序中。
4. Spine.js——優(yōu)點(diǎn)：輕量級(jí)，文檔很完備；缺點(diǎn)：它的核心概念“spine”是異步的用戶界面，這意味著理想狀況用戶界面永遠(yuǎn)不會(huì)發(fā)生堵塞，而這個(gè)基礎(chǔ)有缺陷。
5. Cappuccino——優(yōu)點(diǎn)：大型深思熟慮后的框架，良好的社區(qū)，很棒的繼承模型；缺點(diǎn)：由iOS開發(fā)者創(chuàng)建，使用JavaScript模擬Objective-C。
6. Knockout.js——優(yōu)點(diǎn)：對(duì)綁定的支持，完備的文檔和教程；缺點(diǎn)：綁定語法拙劣，缺少統(tǒng)一的視圖組件層級(jí)關(guān)系。
7. Javascript MVC——優(yōu)點(diǎn)：可靠的社區(qū)；缺點(diǎn)：基于字符串的繼承模型很差，控制器與視圖關(guān)系過密而缺少綁定。
8. GWT（Google Web Toolkit）——優(yōu)點(diǎn)：全面的框架，良好的社區(qū)，可靠的基于Java的組件繼承模型；缺點(diǎn)：可能無法經(jīng)受時(shí)間的考驗(yàn)，另外，Java在客戶端上的抽象有些笨拙。
9. Google Closure——優(yōu)點(diǎn)：很好的基于組件的UI組合系統(tǒng)。缺點(diǎn)：缺少UI綁定支持。
10. Ember.js——優(yōu)點(diǎn)：很豐富的模板系統(tǒng)，擁有復(fù)合視圖和UI綁定；缺點(diǎn)：相對(duì)較新，文檔不夠完備。
11. Angular.js——優(yōu)點(diǎn)：對(duì)模板范圍和控制器設(shè)計(jì)有很好的考慮，擁有依賴注入系統(tǒng)，支持豐富的UI綁定語法。缺點(diǎn)：代碼的模塊性不強(qiáng)，視圖的模塊化也不夠。
12. Batman.js——優(yōu)點(diǎn)：代碼清晰，綁定、持久化的方法簡單；缺點(diǎn)：使用了單例控制器。

最新評(píng)論