2012-12-18 25 views
3

我一直在閱讀Backbone Fundamentals,並且已經計劃在一個新項目中使用中介體和外觀模式,但是在閱讀時,我想知道爲什麼不能使用應用程序主要路由器對象或任何對象擴展了Backbone.Events作爲中介,而不是實現書中概述的訂閱和發佈方法。現在可以將0.9.9中的Backbone對象用作中介替換嗎?

既然Backbone 0.9.9的文檔明確提到了使用Backbone對象(現在從Backbone.Events擴展)作爲全局事件總線,我對此更加好奇。任何人都可以澄清,如果這是一個很好的選擇,如果不是爲什麼?

回答

5

我沒有看到使用Backbone根對象作爲中介的任何問題。將應用程序的主要路由器用作事件總線並不一定是個好主意,因爲這會要求路由器實例可以全局訪問應用程序的每個部分。使用Backbone根對象很大程度上避免了這個缺陷,因爲它已經是一個全局的單例實例。

如果一個人想真正找理由不使用Backbone作爲調解員,你可能會說,這樣做會夫婦所有的出版商和訂戶Backbone,從而降低消費者代碼的可移植性。另外你失去了對你公開的界面的控制。在AMD /模塊模式中,這意味着您必須將Backbone導入到沒有業務訪問Backbone根對象的模塊。

我不認爲這是一個問題,因爲您的應用程序很可能完全依賴於Backbone。但是,如果你感到偏執狂,你可以使用Backbone.Events執行而不暴露全局對象:

//mediator.js 
define(['backbone', 'underscore'], function(Backbone, _) { 
    return _.extend({}, Backbone.Events); 
}); 

在這種情況下,消費者只能使用這個接口,而不是實現的依賴關係,並可能改變實施細則只需通過自己實施onofftrigger方法。

+0

感謝您的信息fencliff,我很欣賞快速的答案。實際上,所討論的應用程序實際上是充分利用了AMD與RequireJS,但是你說得對,因爲每個模塊基本上都是Backbone的依賴(解耦視圖,模型,集合等),所以我同意;我沒有看到使用Backbone對象的問題,無論如何他們已經需要它。現在提供的listenTo和stopListening方法可以輕鬆清理事件偵聽器,這似乎是一個很好的解決方案。再次 謝謝! – garmur

相關問題