我应该使用一个中央事件总线Backbone.js的？ [英] Should I use a central event bus with backbone.js?

问题描述

我目前的工作我的第一次Backbone.js的应用程序。活动的概念是我很熟悉。但我有问题，如果我要使用中央事件调度与否。一般来说，我看到了这两种方法：

I am currently working on my first backbone.js app. The concept of events is quite familiar to me but I am in question if I should use a central event dispatcher or not. Generally I see these two approaches:

• 电线直接事件发布和事件接收在一起。 （我开始使用这种方法。）


• 使用事件总线和电线出版商和接收到该总线。

它是有利于在电子方面使用事件总线。 G。事件的应用程序和可追溯性长时间可维护性？

Is it favorable to use an event bus in terms of e. g. long time maintainability of the app and traceability of events?

推荐答案

是否使用中央事件总线或直接线一起事件应该由个案基础上进行评估。根据不同的情况，有次在这里你将有利于一个比其他。

Whether to use a central event bus or to directly wire events together should be assessed on a case by case basis. Depending on the circumstance, there are times where you will favour one over the other.

我会采用中央事件总线每当我可能由于这样的事实，出版商和接收机不紧密耦合。在我看来，这使得您的code更容易维护和灵活。

I will use a central event bus whenever I can due to the fact that the publisher and receiver are not tightly coupled. In my opinion, this makes your code more maintainable and flexible.

我觉得中央事件总线非常有用的，当你有：

I find central event buses very useful when you have:

1. 单个事件发布实例和大量的事件接收器。


2. 很多事件发布实例和一个单一的事件接收器

在上述情况下，中央事件总线的好处时，事件接收器实例或发布器实例是动态的，因此被创建和销毁在应用程序的生命变得更加明显。作为一个例子，考虑下面的单页的应用程序：

The benefits of the central event bus in the above cases becomes even more apparent when the event receiver instances or publisher instances are dynamic and thus being created and destroyed over the life of the Application. As an example, consider the following single page app:

1. 单页的应用程序必须被拉伸以适应浏览器窗口的宽度。


2. 单页的应用程序主要是一个标签设置的意见，但因为它们是用户创建和销毁的标签数量是动态


3. 标签的内容所不同的是他们有内容的主要区域，必须拉长占其他兄弟元素的宽度
后，以适合可用宽度各不相同

4. 调整需要在因片不断变化的内容很多不同的位置出现。

1. The single page app must stretch to fit the browser window width.
2. The single page app is primarily a tabbed set of views, however the number of tabs is dynamic as they are created and destroyed by users
3. The contents of the tabs are all different with the exception that they have a main area of content that must be stretched to fit the available width after accounting for the width of other sibling elements
4. Resizing needs to occur at many different points due to the contents of tabs continually changing.

在上述情况下，不管具体情况，中央总线模型作品真的很好。一个code例子是：

In the above case, regardless of the specific scenario, the central bus model works really well. A code example would be:

应用级

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);
        });
    }
}

在你的看法

每当有东西需要调整大小，则触发事件，例如：

Whenever a something needs to be resized, you trigger the event, for example:

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

正如你所看到的，这是非常有用的，因为fitRemainingWidth功能，可以在所有适用于任何东西，你永远不知道哪些视图可能要在将来使用它或当它需要被调用。

As you can see, this is really useful, because the fitRemainingWidth function can apply to anything at all and you never know which views may want to use it in the future or when it will need to be called.

所以我想我应该移动到时，我发现不使用中央事件总线preferable。我相信还有其他的情况下，但是最主要的一个对我来说，当接收器需要被连接到出版商的特定实例。例如，如果我们继续与标签的应用实例，可以说，每个选项卡的内容是一个特别的人的邮箱的拆分视图。在每个拆分视图是显示电子邮件的集合，显示当前选定的信息列表中的内容的阅读窗格列表窗格。

So I guess I should move onto when I find not using a central event bus preferable. I am sure there are other cases, however the main one for me is when the receiver needs to be wired to a specific instance of the publisher. For example, if we continue on with the tabbed application example, lets say that the contents of each tab is a split view of a particular person's mailbox. In each split view is a list pane showing a collection of emails and a reading pane showing the content of the currently selected message in the list.

在这种情况下，我们要触发：点击电子邮件时，选择的电子邮件事件，并绑定了，因此可以显示电子邮件的内容，适当的阅读窗格。

In this case we want to trigger a "selected:email" event when an email is clicked and have the appropriate reading pane bound to it so it can display the email's contents.

假设我们有十个邮箱选项卡中打开，每个都有自己的邮件列表窗格和阅读窗格。这使得十个电子邮件列表和十个阅读窗格。如果我是当我引发了使用中央事件总线为这样的场景：从列表中的一个选择电子邮件，即从事件总线接收这些事件的阅读窗格需要有自己的智慧去尝试和工作出所选择的电子邮件是否是东西，他们需要显示或没有。这是不是真的希望每个阅读窗格来尝试和工作了这一点，并没有涉及uneccesary逻辑。其更好的阅读窗格只收到一个：与电子邮件对象选择电子邮件事件，因为它的有效载荷，只是显示它。

Say we have ten mailbox tabs open, each with their own email list pane and reading pane. That makes ten email lists and ten reading panes. If I was to use a central event bus for this scenario when I triggered a "selected:email" from one of the lists, the reading panes that are receiving these events from the event bus would need to have their own smarts to try and work out whether the selected email was something they need to display or not. It's not really desirable for each reading pane to try and work this out and there is uneccesary logic involved. Its far better for a reading pane to just receive a "selected:email" event with the email object as it's payload and just display it.

因此​​，在这种情况下，它能够更好地使每个邮箱选项卡视图负责接线它的事件的具体子视图实例和他们的模型和集合。在我们的例子，这意味着一个电子邮件列表视图与它的收集和阅读窗格视图的特定实例相关联的特定实例。

So in this scenario, its better to to make each mailbox tab view responsible for wiring the events of it's specific child view instances and their models and collections. In our example this means a specific instance of an email list view with it's collection and a specific associated instance of a reading pane view.

综上所述，我建议有使用案例为每，你应该尽量选择上为每一个你遇到的情况是正确的做法明智。同时使用并从中看到在哪些情况下什么适合。

In summary, I am suggesting there are use cases for each and that you should try to be judicious on choosing the right approach for each circumstance that you come across. Use both and learn to see what fits in which circumstances.

最后，关于事件的可追溯性，可以随时写的包装在和关闭在事件总线的功能，无论调用普通在和关闭功能，而且还添加/删除信息包含寄存器哪些对象绑定到该事件。你可以使用这个用于调试和写入有关这些对象的控制台的信息，所以你可以在任何时间点有你的事件总线和听众的状态的清晰画面。我没有想过这样做，但没有理由你不能;）

Lastly, in regards to the traceability of events, you can always write a wrapper for the On and Off functions in your event bus that both calls the normal On and Off functions but also adds/removes information to a register containing which objects are bound to which events. You could use this for debugging and write to the console information about these objects so you can have a clear picture of the state of your event bus and its listeners at any point in time. I've not ever thought about doing this, but there is no reason why you couldn't ;)

帖子编辑的：使用本地事件有关公交车的tsiki评论是一个很好的一个。在我与许多标签邮箱作出了上述例子中，你可以使用一个本地事件总线为每个用户邮箱选项卡视图。你可能想这样做，如果每个邮箱选项卡视图成为包含许多嵌套子视图和大量的事件本身就相当复杂的生成/处理。

Post Edit: The comment by tsiki regarding using Local Event buses is a good one. In the above example I made with many tabbed mailboxes, you could use a local event bus for each user mailbox tab view. You might want to do this if each mailbox tab view became quite complicated in its own right containing many nested child views and large amounts of events to be generated/handled.

这篇关于我应该使用一个中央事件总线Backbone.js的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！