我一直在阅读Backbone Fundamentals并且一直计划在一个新项目中使用中介和外观模式,但是在阅读时我想知道为什么不能只使用应用程序主路由器对象或任何扩展的对象Backbone.Events 作为中介,而不是实现书中概述的订阅和发布方法。
现在 Backbone 0.9.9 的文档明确提到使用 Backbone 对象(现在从 Backbone.Events 扩展)作为全局事件总线,我对此更加好奇。谁能澄清这是否是一个不错的选择,如果不是,为什么?
我一直在阅读Backbone Fundamentals并且一直计划在一个新项目中使用中介和外观模式,但是在阅读时我想知道为什么不能只使用应用程序主路由器对象或任何扩展的对象Backbone.Events 作为中介,而不是实现书中概述的订阅和发布方法。
现在 Backbone 0.9.9 的文档明确提到使用 Backbone 对象(现在从 Backbone.Events 扩展)作为全局事件总线,我对此更加好奇。谁能澄清这是否是一个不错的选择,如果不是,为什么?
我认为使用Backbone
根对象作为中介没有任何问题。将应用程序的主路由器用作事件总线不一定是一个好主意,因为这将要求路由器实例可被应用程序的每个部分全局访问。使用 Backbone 根对象在很大程度上避免了这个陷阱,因为它已经是一个全局单例实例。
如果有人真的想寻找不用Backbone
作中介的理由,您可能会争辩说,这样做会将所有发布者和订阅者耦合到Backbone
.,从而降低消费者代码的可移植性。此外,您失去了对您公开的界面的控制。在 AMD/Module 模式中,这意味着您必须将 Backbone 导入到没有访问Backbone
根对象的业务的模块中。
我不认为这是一个问题,因为您的应用程序很可能完全依赖于 Backbone。但是,如果您感到偏执,则可以在Backbone.Events
不暴露全局对象的情况下使用该实现:
//mediator.js
define(['backbone', 'underscore'], function(Backbone, _) {
return _.extend({}, Backbone.Events);
});
在这种情况下,消费者只依赖接口而不是实现,并且可以通过自己实现on
,off
和trigger
方法来更改中介中介的实现细节。