我应该使用带有backbone.js的中央事件总线吗?

2024-06-25

我目前正在开发我的第一个backbone.js 应用程序。事件的概念对我来说非常熟悉,但我不确定是否应该使用中央事件调度程序。一般来说,我看到这两种方法:

  • 直接将事件发布者和事件接收者连接在一起。 (我从这种方法开始。)
  • 使用事件总线并将发布者和接收者连接到该总线。

就 e 而言,使用事件总线是否有利? G。应用程序的长期可维护性和事件的可追溯性?


是否使用中央事件总线或直接将事件连接在一起应根据具体情况进行评估。根据具体情况,有时您会偏爱其中之一。

由于发布者和接收者没有紧密耦合,我将尽可能使用中央事件总线。在我看来,这使您的代码更易于维护和灵活。

我发现中央活动总线在以下情况下非常有用:

  1. 单个事件发布实例和多个事件接收器。
  2. 许多事件发布实例和单个事件接收器

当事件接收器实例或发布者实例是动态的并且因此在应用程序的生命周期中被创建和销毁时,在上述情况下中央事件总线的好处变得更加明显。作为示例,请考虑以下单页应用程序:

  1. 单页应用程序必须拉伸以适应浏览器窗口宽度。
  2. 单页应用程序主要是一组选项卡式视图,但是选项卡的数量是动态的,因为它们是由用户创建和销毁的
  3. 选项卡的内容都不同,除了它们有一个主要内容区域,在考虑其他同级元素的宽度后,必须拉伸该内容以适应可用宽度
  4. 由于选项卡的内容不断变化,因此需要在许多不同的点调整大小。

在上面的例子中,无论具体场景如何,中央总线模型的效果都非常好。代码示例是:

应用层

var App = {

    init: function () {
        // Event to resize width of element to remaining width
        App.Events.on("fitRemainingWidth:app", this.fitRemainingWidth);
     },

    // event pub sub for the app.
    Events: _.extend({}, Backbone.Events),

    // function that expands an element, or elements to the remaining width in the window. 
    fitRemainingWidth: function(targetEls) {
        var els = $(targetEls);
        _.each(els, function (e) {
            var el = $(e);
            var cont = el.parent();
            newWidth = cont.innerWidth();
            otherElements = cont.children().not(el);
            otherElementsWidth = 0;

            otherElements.each(function () {
                otherElementsWidth += $(this).outerWidth();
            });

            el.width(newWidth - otherElementsWidth);
        });
    }
}

在你看来

每当需要调整某物的大小时,您就会触发该事件,例如:

App.Events.trigger("fitRemainingWidth:app", this.$(".main-content"), this);

正如您所看到的,这确实很有用,因为 fitRemainingWidth 函数可以应用于任何东西,并且您永远不知道哪些视图将来可能想要使用它或何时需要调用它。

所以我想当我发现不使用中央事件总线更好时我应该继续。我确信还有其他情况,但对我来说主要的情况是接收器需要连接到发布者的特定实例。例如,如果我们继续使用选项卡式应用程序示例,可以说每个选项卡的内容是特定人员邮箱的拆分视图。每个拆分视图中都有一个显示电子邮件集合的列表窗格和一个显示列表中当前所选消息内容的阅读窗格。

在本例中,我们希望在单击电子邮件时触发“selected:email”事件,并绑定适当的阅读窗格,以便它可以显示电子邮件的内容。

假设我们打开了十个邮箱选项卡,每个选项卡都有自己的电子邮件列表窗格和阅读窗格。这就形成了十个电子邮件列表和十个阅读窗格。如果我要在这种情况下使用中央事件总线,当我从其中一个列表触发“selected:email”时,从事件总线接收这些事件的阅读窗格将需要拥有自己的智能来尝试工作确定所选电子邮件是否是他们需要显示的内容。并不是每个阅读窗格都尝试解决这个问题,而且其中涉及不必要的逻辑。对于阅读窗格来说,只接收“selected:email”事件并将电子邮件对象作为其有效负载并显示它要好得多。

因此,在这种情况下,最好让每个邮箱选项卡视图负责连接其特定子视图实例及其模型和集合的事件。在我们的示例中,这意味着电子邮件列表视图及其集合的特定实例和阅读窗格视图的特定关联实例。

总之,我建议每种情况都有用例,并且您应该针对遇到的每种情况谨慎选择正确的方法。使用两者并了解什么适合哪种情况。

最后,关于事件的可追溯性,您始终可以为事件编写一个包装器On and Off事件总线中的函数都调用普通函数On and Off函数,还向寄存器添加/删除信息,其中包含哪些对象绑定到哪些事件。您可以使用它进行调试并将有关这些对象的信息写入控制台,以便您可以清楚地了解事件总线及其侦听器在任何时间点的状态。我从来没有想过这样做,但你没有理由不这样做;)

帖子编辑

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

我应该使用带有backbone.js的中央事件总线吗? 的相关文章

随机推荐