PDF版的PPT下載地址：http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture

注：在整理的過程中，發(fā)現(xiàn)作者有些思想是返來復(fù)去地說，所以刪減了一部分，如果你的英文良好，請直接閱讀英文的PPT。

以下是本文的主要章節(jié)：

1. 什么叫“JavaScript大型程序”？

2. 顧當(dāng)前的程序架構(gòu)

3. 長遠考慮

4. 頭腦風(fēng)暴

5. 建議的架構(gòu)

   5.1 設(shè)計模式

        5.1.1 模塊論

            5.1.1.1 綜述

            5.1.1.2 Module模式

            5.1.1.3 對象自面量

            5.1.1.4 CommonJS模塊

        5.1.2 Facade模式

        5.1.3 Mediator模式

    5.2 應(yīng)用到你的架構(gòu)

        5.2.1 Facade - 核心抽象

        5.2.2 Mediator - 程序核心

        5.2.3 緊密聯(lián)合運作起來

6. 發(fā)布Pub/訂閱Sub的延伸：自動注冊事件

7. Q & A

8. 致謝

什么叫“JavaScript大型程序”？

在我們開始之前，我們來定義一下什么叫大型JavaScript站點，很多有經(jīng)驗的JS開發(fā)高手也都被challenge住了，有人說超過10萬行JavaScript代碼才算大型，也有人說JavaScript代碼要超過1MB大小才算，其實2者都不能算對，因為不能安裝代碼量的多少來衡量，很多瑣碎的JS代碼很容易超過10萬行的。

我對“大”的定義如下，雖然可能不太對，但是應(yīng)該是比較接近了：

我個人認為，大型JavaScript程序應(yīng)該是非常重要并且融入了很多卓越開發(fā)人員努力，對重量級數(shù)據(jù)進行處理并且展示給瀏覽器的程序。

回顧當(dāng)前的程序架構(gòu)

我不能強調(diào)說這個問題有多重要，很多有經(jīng)驗的開發(fā)人員經(jīng)常說：“現(xiàn)有的創(chuàng)意和設(shè)計模式在我上一個中型項目上運行得非常好，所以在稍微大型點的程序里再次使用，應(yīng)該沒問題，對吧？”,在一定程序上是沒錯的，但別忘記了，既然是大型程序，通常就應(yīng)該有大的Concerns需要分解關(guān)注，我簡短解釋一下要花時間來review當(dāng)前運行了很久的程序架構(gòu)。大多數(shù)情況下，當(dāng)前的JavaScript程序架構(gòu)應(yīng)該是如下這個樣子的（注意，是JS架構(gòu)，不是大家常說的ASP.NET MVC）：
    custom widgets
    models
    views
    controllers
    templates
    libraries/toolkits
    an application core.

你可能還會將程序單獨封裝成多個modules，或者使用其他的設(shè)計模式，這很好，但是如果這些結(jié)構(gòu)完全代表你的架構(gòu)的話，就可能會有一些潛在的問題，我們來看看幾個重要的點：

1.你架構(gòu)里的東西，有多少可以立即拿出來重用？
有沒有一些單獨的module不依賴別的代碼？是自包含么？如果我到你們正在使用的代碼庫上去隨即挑選一些模塊module代碼，然后放在一個新頁面，是否能立即就能使用？你可能會說原理通就可以了，我建議你長久打算一下，如果你的公司之前開發(fā)很多重要的程序，突然有一天有人說，這個項目里的聊天模塊不錯，我們拿出來放在另外一個項目里吧，你能直接拿過來不修改代碼就能使用么？

2.系統(tǒng)里有多少模塊module需要依賴其他模塊？
系統(tǒng)的各個模塊是不是都很緊耦合？在我將這個問題作為concern之前，我先解釋一下，不是說所有的模塊都絕對不能有任何依賴，比如一個細粒度的功能可能是從base功能擴展來的，我的問題和這種情況不一樣，我說的是不同功能模塊之前的依賴，理論上，所有的不同功能模塊都不應(yīng)該有太多的依賴。

3.如果你程序的某一部分出錯了，其他部分是否能夠依然工作？
如果你構(gòu)建一個和Gmail差不多的程序，你可以發(fā)現(xiàn)Gmail里很多模塊都是動態(tài)加載的，比如聊天chat模塊，在初始化頁面的時候是不加載的，而且就算加載以后出錯了，頁面的其他部分也能正常使用。

4.你的各個模塊Module能很簡單的進行測試么？
你的每一個模塊都有可能用在數(shù)百萬用戶的大型站點上，甚至多個站點都使用它，所以你的模塊需要能經(jīng)得住測試，也就是說，不管是在架構(gòu)內(nèi)部還是架構(gòu)外部，都應(yīng)該能很簡單的去測試，包括大部分的斷言在不同的環(huán)境下都能夠通過。

長遠考慮

架構(gòu)大型程序的時候，最重要的是要有前瞻性，不能只考慮一個月或者一年以后的情況，要考慮更長久的情況下，有什么改變的可能性？開發(fā)人員經(jīng)常將DOM操作的代碼和程序綁定得太緊，盡管有時候已經(jīng)封裝單獨的邏輯到不同的模塊里了，想想一下，長久以后，為什么不是很好。

我的一個同事曾經(jīng)說過，一個精確的架構(gòu)可能不適合未來的情景，有時候是正確的，但是當(dāng)你需要該做的話，你所付出的money那可是相當(dāng)?shù)囟嗯?。比如，你可能因為某些性能，安全，設(shè)計的原因需要在Dojo, jQuery, Zepto, YUI之間需要選擇替換，這時候就有問題了，大部分模塊都有依賴，需要錢呀，需要時間啊，需要人呀，對不？

對于一些小型站點沒事，但是大型站點確實需要提供一個更加靈活的機制，而不去擔(dān)心各個模塊之間的各種問題，這既然節(jié)約錢，又能節(jié)約時間。

總結(jié)一下，現(xiàn)在你能確定你能不重寫整個程序就能替換一些類庫么？如果不能，那估計我們下面要講的內(nèi)容，就比較適合你了。

很多有經(jīng)驗的JavaScript開發(fā)者給出了一些關(guān)鍵的notes：

JavaScriptMVC的作者Justin Meyer說：

構(gòu)建大型程序最大的秘密就是從來不構(gòu)建大型程序，而是將程序分解成各個小的模塊去做，讓每個小模塊都可測試，可size化，然后集成到程序里。

High-performance JavaScript websites作者Nicholas,Zakas：
"The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don't know everything, you begin to design the system defensively. You identify the key areas that may change, which often is very easy when you put a little bit of time into it. For instance, you should expect that any part of the app that communicates with another system will likely change, so you need to abstract that away." -

一大堆文字問題，太麻煩了，總結(jié)一句就是，一切皆可變，所以要抽象。

jQuery Fundamentals作者Rebecca Murphey：
各個模塊之間聯(lián)系的越密切，重用性越小，改變起來困難越大。

以上這些重要觀點，是構(gòu)建架構(gòu)的核心要素，我們需要時刻銘記。

頭腦風(fēng)暴

我們來頭腦風(fēng)暴一下，我們需要一個松耦合的架構(gòu)，各模塊之間沒有依賴，各個模塊和程序進行通信，然后中間層接管和處理反饋相應(yīng)的消息。

例如，我們?nèi)绻幸粋€JavaScript構(gòu)建在線面包店程序，一個模塊發(fā)出了一個信息可能是“有42個圓面包需要派件”。我們使用不同的layer層來處理模塊發(fā)來的消息，做到如下：

    模塊不直接訪問程序核心
    模塊不直接調(diào)用或影響其它的模塊

這將防止我們因為某個模塊出錯，而導(dǎo)致所有的模塊出錯。

另外一個問題是安全，真實的情況是，大多數(shù)人都不認為內(nèi)部安全是個問題，我們自己心里說，程序是我自己構(gòu)建的，我知道哪些是公開的那些私有的，安全沒問題，但你有沒有辦法去定義哪個模塊才能權(quán)限訪問程序核心？例如，有一個chat聊天模塊，我不想讓他調(diào)用admin模塊，或者不想讓它調(diào)用有DB寫權(quán)限的模塊，因為這之間存在很脆弱，很容易導(dǎo)致XSS攻擊。每個模塊不應(yīng)該能做所有的事情，但是當(dāng)前大多數(shù)架構(gòu)里的JavaScript代碼都有這種的問題。提供一個中間層來控制，哪個模塊可以訪問那個授權(quán)的部分，也就是說，該模塊最多只能做到我們所授權(quán)的那部分。

建議的架構(gòu)

我們本文的重點來了，這次我們提議的架構(gòu)使用了我們都很熟知的設(shè)計模式：module, facade和mediator。

和傳統(tǒng)的模型不一樣的是，為了解耦各個模塊，我們只讓模塊發(fā)布一些event事件，mediator模式可以負責(zé)從這些模塊上訂閱消息message，然后控制通知的response，facade模式用戶限制各模塊的權(quán)限。

以下是我們要注意講解的部分：
    1 設(shè)計模式
        1.1 模塊論
            1.1.1 綜述
            1.1.2 Module模式
            1.1.3 對象自面量
            1.1.4 CommonJS模塊
        1.2 Facade模式
        1.3 Mediator模式
    2 應(yīng)用到你的架構(gòu)
        2.1 Facade - 核心抽象
        2.2 Mediator - 程序核心
        2.3 緊密聯(lián)合運作起來

模塊論

大家可能都或多或少地使用了模塊化的代碼，模塊是一個完整的強健程序架構(gòu)的一部分，每個模塊都是為了單獨的目的為創(chuàng)建的，回到Gmail，我們來個例子，chat聊天模塊看起來是個單獨的一部分，其實它是有很多單獨的子模塊來構(gòu)成，例如里面的表情模塊其實就是單獨的子模塊，也被用到了發(fā)送郵件的窗口上。

另外一個是模塊可以動態(tài)加載，刪除和替換。

在JavaScript里，我們又幾種方式來實現(xiàn)模塊，大家熟知的是module模式和對象字面量,如果你已經(jīng)熟悉這些，請忽略此小節(jié)，直接跳到CommonJS部分。

Module模式

module模式是一個比較流行的設(shè)計模式，它可以通過大括號封裝私有的變量，方法，狀態(tài)的，通過包裝這些內(nèi)容，一般全局的對象不能直接訪問，在這個設(shè)計模式里，只返回一個API，其它的內(nèi)容全部被封裝成私有的了。

另外，這個模式和自執(zhí)行的函數(shù)表達式比較相似，唯一的不同是module返回的是對象，而自執(zhí)行函數(shù)表達式返回的是function。

眾所周知， JavaScript不想其它語言一樣有訪問修飾符，不能為每個字段或者方法聲明private,public修飾符，那這個模式我們是如何實現(xiàn)的呢？那就是return一個對象，里面包括一些公開的方法，這些方法有能力去調(diào)用內(nèi)部的對象。

看一下，下面的代碼，這段代碼是一個自執(zhí)行代碼，聲明里包括了一個全局的對象basketModule， basket數(shù)組是一個私有的，所以你的整個程序是不能訪問這個私有數(shù)組的，同時我們return了一個對象，其內(nèi)包含了3個方法（例如addItem,getItemCount,getTotal)，這3個方法可以訪問私有的basket數(shù)組。

var basketModule = (function() {
var basket = []; //private
return { //exposed to public
　　addItem: function(values) {
　　　　basket.push(values);
　　},
　　getItemCount: function() {
　　　　return basket.length;
　　},
　　getTotal: function(){
　　　　var q = this.getItemCount(),p=0;
　　　　while(q--){
　　　　p+= basket[q].price;
　　　　}
　　　　return p;
　　}
　}
}());

同時注意，我們return的對象直接賦值給了basketModule，所以我們可以像下面一樣使用：

//basketModule is an object with properties which can also be methods
basketModule.addItem({item:'bread',price:0.5});
basketModule.addItem({item:'butter',price:0.3});
 
console.log(basketModule.getItemCount());
console.log(basketModule.getTotal());
 
//however, the following will not work:
console.log(basketModule.basket);// (undefined as not inside the returned object)
console.log(basket); //(only exists within the scope of the closure)

那在各個流行的類庫（如Dojo, jQuery)里是如何來做呢？

Dojo

Dojo試圖使用dojo.declare來提供class風(fēng)格的聲明方式，我們可以利用它來實現(xiàn)Module模式，例如如果你想再store命名空間下聲明basket對象，那么可以這么做：

//traditional way
var store = window.store || {};
store.basket = store.basket || {};
 
//using dojo.setObject
dojo.setObject("store.basket.object", (function() {
　　var basket = [];
　　function privateMethod() {
　　　　console.log(basket);
　　}
　　return {
　　　　publicMethod: function(){
　　　　　　privateMethod();
　　　　}
　　　};
}()));

結(jié)合dojo.provide一起來使用，非常強大。

YUI

下面的代碼是YUI原始的實現(xiàn)方式：

YAHOO.store.basket = function () {

 //"private" variables:
 var myPrivateVar = "I can be accessed only within YAHOO.store.basket .";

 //"private" method:
 var myPrivateMethod = function () {
 YAHOO.log("I can be accessed only from within YAHOO.store.basket");
 }

 return {
 myPublicProperty: "I'm a public property.",
 myPublicMethod: function () {
  YAHOO.log("I'm a public method.");

  //Within basket, I can access "private" vars and methods:
  YAHOO.log(myPrivateVar);
  YAHOO.log(myPrivateMethod());

  //The native scope of myPublicMethod is store so we can
  //access public members using "this":
  YAHOO.log(this.myPublicProperty);
 }
 };

} (); 

jQuery

jQuery里有很多Module模式的實現(xiàn)，我們來看一個不同的例子，一個library函數(shù)聲明了一個新的library，然后創(chuàng)建該library的時候，在document.ready里自動執(zhí)行init方法。

function library(module) {
　　$(function() {
　　　　if (module.init) {
　　　　　　module.init();
　　　　}
　　});
　　return module;
}
 
var myLibrary = library(function() {
　　return {
　　　　init: function() {
　　　　　　/*implementation*/
　　　　　　}
　　};
}());

對象自面量

對象自面量使用大括號聲明，并且使用的時候不需要使用new關(guān)鍵字，如果對一個模塊里的屬性字段的publice/private不是很在意的話，可以使用這種方式，不過請注意這種方式和JSON的不同。對象自面量：var item={name: "tom", value:123} JSON:var item={"name":"tom", "value":123}。

var myModule = {
 myProperty: 'someValue',
 //object literals can contain properties and methods.
 //here, another object is defined for configuration
 //purposes:
 myConfig: {
 useCaching: true,
 language: 'en'
 },
 //a very basic method
 myMethod: function () {
 console.log('I can haz functionality?');
 },
 //output a value based on current configuration
 myMethod2: function () {
 console.log('Caching is:' + (this.myConfig.useCaching) ? 'enabled' : 'disabled');
 },
 //override the current configuration
 myMethod3: function (newConfig) {
 if (typeof newConfig == 'object') {
  this.myConfig = newConfig;
  console.log(this.myConfig.language);
 }
 }
};

 
myModule.myMethod(); //I can haz functionality
myModule.myMethod2(); //outputs enabled
myModule.myMethod3({ language: 'fr', useCaching: false }); //fr

CommonJS

關(guān)于 CommonJS的介紹，這里就不多說了，之前很多文章都有介紹，我們這里要提一下的是CommonJS標準里里有2個重要的參數(shù)exports和require，exports是代表要加載的模塊，require是代表這些加載的模塊需要依賴其它的模塊，也需要將它加載進來。

/*
Example of achieving compatibility with AMD and standard CommonJS by putting boilerplate around the standard CommonJS module format:
*/
 
(function(define){
　　define(function(require,exports){
　　　　// module contents
　　　　var dep1 = require("dep1");
　　　　exports.someExportedFunction = function(){...};
　　　　//...
　　});
})(typeof define=="function"?define:function(factory){factory(require,exports)});

有很多CommonJS標準的模塊加載實現(xiàn)，我比較喜歡的是RequireJS，它能否非常好的加載模塊以及相關(guān)的依賴模塊，來一個簡單的例子，例如需要將圖片轉(zhuǎn)化成ASCII碼，我們先加載encoder模塊，然后獲取他的encodeToASCII方法，理論上代碼應(yīng)該是如下：

var encodeToASCII = require("encoder").encodeToASCII;
exports.encodeSomeSource = function(){
　　//其它操作以后，然后調(diào)用encodeToASCII
}

但是上述代碼并沒用工作，因為encodeToASCII函數(shù)并沒用附加到window對象上，所以不能使用，改進以后的代碼需要這樣才行：

define(function(require, exports, module) {
　　var encodeToASCII = require("encoder").encodeToASCII;
　　　　exports.encodeSomeSource = function(){
　　　　//process then call encodeToASCII
　　}
});

CommonJS 潛力很大，但是由于大叔不太熟，所以就不過多地介紹了。

Facade模式

Facade模式在本文架構(gòu)里占有重要角色，關(guān)于這個模式很多JavaScript類庫或者框架里都有體現(xiàn)，其中最大的作用，就是包括High level的API，以此來隱藏具體的實現(xiàn)，這就是說，我們只暴露接口，內(nèi)部的實現(xiàn)我們可以自己做主，也意味著內(nèi)部實現(xiàn)的代碼可以很容易的修改和更新，比如今天你是用jQuery來實現(xiàn)的，明天又想換YUI了，這就非常方便了。

下面這個例子了，可以看到我們提供了很多私有的方法，然后通過暴露一個簡單的 API來讓外界執(zhí)行調(diào)用內(nèi)部的方法：

var module = (function () {
 var _private = {
 i: 5,
 get: function () {
  console.log('current value:' + this.i);
 },
 set: function (val) {
  this.i = val;
 },
 run: function () {
  console.log('running');
 },
 jump: function () {
  console.log('jumping');
 }
 };
 return {
 facade: function (args) {
  _private.set(args.val);
  _private.get();
  if (args.run) {
  _private.run();
  }
 }
 }
} ());

module.facade({run:true, val:10});
//outputs current value: 10, running

Facade和下面我們所說的mediator的區(qū)別是，facade只提供現(xiàn)有存在的功能，而mediator可以增加新功能。

 Mediator模式

講modiator之前，我們先來舉個例子，機場飛行控制系統(tǒng)，也就是傳說中的塔臺，具有絕對的權(quán)利，他可以控制任何一架飛機的起飛和降落時間以及地方，而飛機和飛機之前不允許通信，也就是說塔臺是機場的核心，mediator就相當(dāng)于這個塔臺。

mediator就是用在程序里有多個模塊，而你又不想讓各個模塊有依賴的話，那通過mediator模式可以達到集中控制的目的。實際場景中也是，mediator封裝了很多不想干的模塊，讓他們通過mediator聯(lián)系在一起，同時也松耦合他們，使得他們之間必須通過mediator才能通信。

那mediator模式的優(yōu)點是什么？那就是解耦，如果你之前對觀察者模式比較了解的話，那理解下面的mediator圖就相對簡單多了，下圖是一個high level的mediator模式圖：

想想一下，各模塊是發(fā)布者，mediator既是發(fā)布者又是訂閱者。

    Module 1向Mediator廣播一個實際，說需要做某事
    Mediator捕獲消息以后，立即啟動處理該消息需要使用的Module 2，Module 2處理結(jié)束以后返回信息給Mediator
    與此同時，Mediator也啟動了Module 3，當(dāng)接受Module 2 返回消息的時候自動記錄日志到Module 3里

可以看到，各模塊之間并沒有通信，另外Mediator也可以實現(xiàn)監(jiān)控各模塊狀態(tài)的功能，例如如果Module 3出錯了，Mediator可以暫時只想其它模塊，然后重啟Module 3，然后繼續(xù)執(zhí)行。

回顧一下，可以看到，Mediator的優(yōu)點是：松耦合的模塊由同一的Mediator來控制，模塊只需要廣播和監(jiān)聽事件就可以了，而模塊之間不需要直接聯(lián)系，另外，一次信息的處理可以使用多個模塊，也方便我們以后統(tǒng)一的添加新的模塊到現(xiàn)有的控制邏輯里。

確定是：由于所有的模塊直接都不能直接通信，所有相對來說，性能方面可能會有少許下降，但是我認為這是值得的。

我們根據(jù)上面的講解來一個簡單的Demo：

var mediator = (function(){
 var subscribe = function(channel, fn){
 if (!mediator.channels[channel]) mediator.channels[channel] = [];
 mediator.channels[channel].push({ context: this, callback: fn });
 return this;
 },
 
 publish = function(channel){
 if (!mediator.channels[channel]) return false;
 var args = Array.prototype.slice.call(arguments, 1);
 for (var i = 0, l = mediator.channels[channel].length; i < l; i++) {
  var subscription = mediator.channels[channel][i];
  subscription.callback.apply(subscription.context, args);
 }
 return this;
 };
 
 return {
 channels: {},
 publish: publish,
 subscribe: subscribe,
 installTo: function(obj){
  obj.subscribe = subscribe;
  obj.publish = publish;
 }
 };
 
}());

然后有2個模塊分別調(diào)用：

//Pub/sub on a centralized mediator
 
mediator.name = "tim";
mediator.subscribe('nameChange', function(arg){
 console.log(this.name);
 this.name = arg;
 console.log(this.name);
});
 
mediator.publish('nameChange', 'david'); //tim, david
 
 
//Pub/sub via third party mediator
 
var obj = { name: 'sam' };
mediator.installTo(obj);
obj.subscribe('nameChange', function(arg){
 console.log(this.name);
 this.name = arg;
 console.log(this.name);
});
 
obj.publish('nameChange', 'john'); //sam, john

應(yīng)用Facade: 應(yīng)用程序核心的抽象

一個facade是作為應(yīng)用程序核心的一個抽象來工作的，在mediator和模塊之間負責(zé)通信，各個模塊只能通過這個facade來和程序核心進行通信。作為抽象的職責(zé)是確保任何時候都能為這些模塊提供一個始終如一的接口（consistent interface），和sendbox controller的角色比較類似。所有的模塊組件通過它和mediator通信，所以facade需要是可靠的，可信賴的，同時作為為模塊提供接口的功能，facade還需要扮演另外一個角色，那就是安全控制，也就是決定程序的哪個部分可以被一個模塊訪問，模塊組件只能調(diào)用他們自己的方法，并且不能訪問任何未授權(quán)的內(nèi)容。例如，一個模塊可能廣播dataValidationCompletedWriteToDB，這里的安全檢查需要確保該模塊擁有數(shù)據(jù)庫的寫權(quán)限。

總之，mediator只有在facade授權(quán)檢測以后才能進行信息處理。

應(yīng)用Mediator：應(yīng)用程序的核心

Mediator是作為應(yīng)用程序核心的角色來工作的，我們簡單地來說一下他的職責(zé)。最核心的工作就是管理模塊的生命周期（lifecycle），當(dāng)這個核心撲捉到任何信息進來的時候，他需要判斷程序如何來處理——也就是說決定啟動或停止哪一個或者一些模塊。當(dāng)一個模塊開始啟動的時候，它應(yīng)該能否自動執(zhí)行，而不需要應(yīng)用程序核心來決定是否該執(zhí)行（比如，是否要在DOM ready的時候才能執(zhí)行），所以說需要模塊自身需要去判定。

你可能還有問題，就是一個模塊在什么情況下才會停止。當(dāng)程序探測到一個模塊失敗了，或者是出錯了，程序需要做決定來防止繼續(xù)執(zhí)行該模塊里的方法，以便這個組件可以重新啟動，目的主要是提高用戶體驗。

另外，該核心應(yīng)該可以動態(tài)添加或者刪除模塊，而不影響其他任何功能。常見的例子是，一個模塊在頁面加載初期是不可用，但是用戶操作以后，需要動態(tài)加載這個模塊然后執(zhí)行，就像Gmail里的chat聊天功能一樣，從性能優(yōu)化的目的來看，應(yīng)該是很好理解的吧。

異常錯誤處理，也是由應(yīng)用程序核心來處理的，另外各模塊在廣播信息的時候，也廣播任何錯誤到該核心里，以便程序核心可以根據(jù)情況去停止/重啟這些模塊。這也是松耦合架構(gòu)一個很重要的部分，我們不需要手工改變?nèi)魏文K，通過mediator使用發(fā)布/訂閱就可以來做到這個。

組裝起來

各模塊包含了程序里各種各樣的功能，他們有信息需要處理的時候，發(fā)布信息通知程序（這是他們的主要職責(zé)），下面的QA小節(jié)里提到了，模塊可以依賴一些DOM工具操作方法，但是不應(yīng)該和系統(tǒng)的其它模塊有依賴，一個模塊不應(yīng)該關(guān)注如下內(nèi)容：

    1.哪個對象或者模塊訂閱了這個模塊發(fā)布的信息
    2.這些對象是客戶端對象還是服務(wù)器端對象
    3.多少對象訂閱了你的信息

Facade抽象應(yīng)用程序的核心，避免各個模塊之間直接通信，它從各模塊上訂閱信息，也負責(zé)授權(quán)檢測，確保每個模塊有用自己單獨的授權(quán)。

Mediator(應(yīng)用程序核心）使用mediator模式扮演發(fā)布/訂閱管理器的角色，負責(zé)模塊管理以及啟動/停止模塊執(zhí)行，可以動態(tài)加載以及重啟有錯誤的模塊。

這個架構(gòu)的結(jié)果是：各模塊之間沒有依賴，因為松耦合的應(yīng)用，它們可以很容易地被測試和維護，各模塊可以很容易地在其它項目里被重用，也可以在不影響程序的情況下動態(tài)添加和刪除。

發(fā)布Pub/訂閱Sub的延伸：自動注冊事件（Automatic Event Registration)

關(guān)于自動注冊事件，需要遵守一定的命名規(guī)范，比如如果一個模塊發(fā)布了一個名字為messageUpdate的事件，那么所有帶有messageUpdate方法的模塊都會被自動執(zhí)行。有好處也有利弊，具體實現(xiàn)方式，可以看我另外一篇帖子：jQuery自定義綁定的魔法升級版。

QA
1.有可能不使用facade或者類似的sandbox模式么？

盡管架構(gòu)的大綱里提出了facade可以實現(xiàn)授權(quán)檢查的功能，其實完全可能由mediator去做，輕型架構(gòu)要做的事情其實是幾乎一樣的，那就是解耦，確保各模塊直接和應(yīng)用程序核心通信是沒問題的就行。

2.你提高了模塊直接不能有依賴，是否意味著不能依賴任何第三方類庫（例如jQuery）。

這其實就是一個兩面性的問題，我們上面說到了，一個模塊也許有一些子模塊，或者基礎(chǔ)模塊，比如基本的DOM操作工具類等，在這個層面上講，我們是可以用第三方類庫的，但是請確保，我們可以很容易地能否替換掉他們。

3.我喜歡這個架構(gòu)，并且想開始使用這個架構(gòu)，有任何代碼樣本可以參考么？

我打算去搞一份代碼樣本供大家參考，不過在這之前，你可以參考Andrew Burgees的帖子Writing Modular JavaScript 。

4.如果模塊需要和應(yīng)用程序核心直接通信，是否可行？

技術(shù)上來將，沒有理由現(xiàn)在模塊不能和應(yīng)用程序核心直接通信，但是對于大多數(shù)應(yīng)用體驗來說，還是不要。既然你選擇了這個架構(gòu)，那就要遵守該架構(gòu)所定義的規(guī)則。

致謝

感謝Nicholas Zakas的原始貼，將思想總結(jié)在一起,感謝Andree Hansson的technical review,感謝Rebecca Murphey, Justin Meyer, John Hann, Peter Michaux, Paul Irish和Alex Sexton,他們所有的人都提供了和本Session相關(guān)的很多資料。