摘要：所以大量的問題都留給開發者自己想辦法來解決，因此遭到吐槽當然，使用純開發一個復雜應用時，情況就會變得非常糟糕。管理復雜的交互自己維護。影響了集合的排列。在中調用這樣做是不對的，因為會讓應用越來越復雜的。

只扯蛋，不給代碼，就是耍流氓 -- honger。

完整的 tutorial 代碼 戳這里， 因為我使用的是 commonjs 規范，基于 spm 的，你可以先安裝,然后運行它。更多 spm 資料

// 安裝
npm install spm -g

// 運行
spm server

這個 repo 是我學習各種技術棧的一個集合，如果是初學者，可以跟我一起來學習，也可以私信我。

你也可以 find me on GitHub

Backbone.Marionette 的中文資料真是少之又少，因此這篇會盡量介紹的較為詳細。

很多人抱怨和吐槽 Backbone , 覺得它太簡單了。什么事都要自己做。然而，Backbone 的優點也是它太簡單了，它的思想就是不作任何綁定， 只提供一個骨架。正如 Backbone 的中文意思。

所以大量的問題都留給開發者自己想辦法來解決，因此遭到吐槽...

當然，使用純 Backbone 開發一個復雜應用時，情況就會變得非常糟糕。

純 Backbone 的工作流程是這樣的： MVP

                      events                               commands
Template/DOM (View) ----------> Backbone.View (Presenter) ----------> Backbone.Model (Model)
        |                           |         |                                 |
        |            updates        |         |             events              |
        |<--------------------------|         |<--------------------------------|

其中涉及的問題有：

業務邏輯: model 和 collection 處理大部分邏輯。他們對應著服務端后臺的資源，也對應著視圖顯示的類容。

構建 DOM：一般是 handlebars。

視圖邏輯：Backbone.View ，其中的邏輯要自己維護。

視圖和模型同步: 自己維護。

管理復雜的 UI 交互：自己維護。

管理狀態和路由：Backbone.Router（不支持管理視圖和應用狀態）

創建與連接組件: 手動實現。

那么，這篇文章著重于講 UI 交互，所有的 UI 交互都可以被劃分為：

簡單交互：使用觀察者同步（Observer Synchronization），被動控制顯示，操作 DOM 事件來改變集合模型，視圖監聽集合模型的變化來改變自身。Backbone.View 就是這樣工作的。

復雜交互：使用流同步（Flow Synchronization），主動控制顯示 SUPERVISING PRESENTERS

使用 Marionette 工作流程是這樣的：

                         events for
                     complex interactions                                  notice
Template/DOM (View) ----------------------> Marionette.View (Presenter) ------------> Backbone.Model (Model)
        |                                           |        |                                |
        |               complex updates             |        |             events             |
        |<------------------------------------------|        |<-------------------------------|
                                                             |                                |
                                                             |        simple updates          |
                                                             |------------------------------->|

Marionette 擴展了非常豐富的視圖 View 組件：ItemView CollectionView CompositeView LayoutView .

不僅于此，Marionette 還使用 Region （區域）來配合 View （視圖）。

一般會先添加一個 Region 來定位一塊地方，再決定這塊地方顯示哪個 View 。

// 你可以理解為一個中心 APP 對象。當一切準備就緒的時候，調用 App.start(options) 啟動應用。
var MyApp = new Backbone.Marionette.Application();

// 添加一個 region，它對應一個 dom 節點
App.addRegions({
  mainRegion: "#content"
});

// 讓這個 region 顯示一個視圖, 這個視圖會立即渲染
App.mainRegion.show(new MyView());

從頭說起吧，你可能注意到了，上面實例化了一個 Marionette.Application 對象。

通常需要定義一個 App ，通過 Initializers 把所有的事都綁定在上面。等待 start 方法調用的時候，開始執行。

// start 方法調用后，立即執行 Initializers
MyApp.addInitializer(function(options) {
  // 實例化 compositeView
  var angryCatsView = new AngryCatsView({
    collection: options.cats
  });
  // 顯示這個視圖
  MyApp.mainRegion.show(angryCatsView);
})

MyApp.start({cats: cats});

這里只綁定了一個 Initializer，在一個復雜的應用中，你可能會綁定多個的。start(options) 中的參數 options 會傳遞個每個 Initializer。

通過擴展 Backbone.Events, 實現 Aspect（切面編程） 你可以監聽這些事件，讓應用更加靈活。

之前分析過 Arale 的 Events 代碼，現在的 Backbone.Events 就是從 Arale 的 Events 合并過來的，看我的 gitbook

App.on("initialize:before", function(options) {
     // doSomething...
});
App.on("initialize:after", function(options) {
     // doOtherthing...
});
App.on("start", function(options) {
  Backbone.history.start();
});

好了，現在已經知道了 Marionette 是怎么啟動的了，下一步是了解它是怎么管理視圖 View 的。

布局視圖，比如你的界面上可能用 header main footer 等區域。

你可以這樣來定義布局視圖，這樣你就掌控全局了。

var RootLayout = Backbone.Marionette.LayoutView.extend({

  el: "#content",

  regions: {
    header: "#header",
    main: "#main",
    footer: "#footer"
  }

})

一般會把這個 root 掛載到 App 上。

var MyApp = Backbone.Marionette.Application.extend({
  setRootLayout: function () {
    this.root = new RootLayout();
  }
});

// App 啟動前，實例化它，得到 App.root
MyApp.on("before:start", function () {
  MyApp.setRootLayout();
});

現在 App 上有了 root 的控制權了，可以任意設置某個區域顯示某個視圖了。

MyApp.root.showChildView("header", new HeaderLayout());

單條記錄 Model 對應 ItemView, CompositeView 不僅對應的是一個包含 ItemView ，還對應有其他一些相關視圖.

他們通常在一起使用，并且 ItemView 是 CompositeView 的 childView 屬性值。

比如這樣兩個 template

  Name





{{name}}

我需要在 tbody 標簽下加入多個 ItemView。這樣你就需要使用 childViewContainer 來指定 childView 被加在什么地方。

很顯然此處： {childViewContainer: "tbody"}.

這里是以上代碼

var AngryCatView = Backbone.Marionette.ItemView.extend({
  template: require("./tpl/angrycat.handlebars"),
  tagName: "tr",
  className: "angry_cat"
});

var AngryCatsView = Backbone.Marionette.CompositeView.extend({

  tagName: "table",
  id: "angry_cats",
  className: "table-striped table-bordered",

  template: require("./tpl/angrycats.handlebars"),

  childView: AngryCatView,

  childViewContainer: "tbody"

})

細心的童鞋應該已經注意到了，模板中為什么不用 table 標簽包裹起來。這是因為 Marionette 會為你包裹一層，若你不指定 tagName 則默認是 div 標簽。 指定的 className, id 屬性也是加在這層上面的。

純 Backbone 代碼需要自己來實現 render 渲染 DOM，在這里 Marionette 通過指定的 template 屬性自動渲染了。

重點 在 這一層 我們要做的是監聽 Model，Collection 的變化，來同步視圖。和 Backbone 做法一樣。不同的是，Marionette 可以指定是全部重繪（render）還是部分重繪（renderCollection）

事件聚合器，這個東西主要是用來解耦的，例如：從 ItemView 上來個事件，改變了 model 的屬性。影響了集合的排列。需要更新到 CompositeView 上。

在 ItemView 中調用 CompositeView ？ 這樣做是不對的，因為會讓應用越來越復雜的。視圖 View 也不應該去處理 business logic。

使用 Event Aggregator 會讓程序解耦，它相當于一種 Publish/Subscribe 模式。視圖只需要去通知 notice 模型 Model or Collection 來處理。

MyApp.trigger("rank:up", this.model);

在模型 Model or Collection 初始化的時候就要 Subscribe 訂閱事件 rank:up

MyApp.on("rank:up", function(cat) {
  if (cat.get("rank") === 1) {
    return true;
  }
  self.rankUp(cat);
  self.sort();
})

這樣的話，business logic 就是在 Model or Collection 中維護的。

Marionette.View 在 Backbone.View 之上多做了很多事情，包括自動渲染和重繪等等。

Marionette.View 接到 Dom 事件后，可以通知 notice 集合 Collection 去處理。也可以直接命令 commands 模型 Model 去處理。

（這里只介紹了一些入門知識 Marionette 未完待續...）