GWT中事件总线的动机

Question

我正在GWT中创建一个类似MVP的应用程序。

• 有多个面板，每个面板始终可见。
• 每个面板都有一个Presenter，并且有一个AppController位于所有演示者之上。
• 在一个Presenter中会出现一些应用程序级事件，但会对其他演示者产生影响。
• 建议的架构似乎涉及事件总线。但是，我不确定我是否看到了比较简单的优势。
• 特别是，简单地允许AppController（并且只有AppController）订阅来自任何Presenter的事件会更清晰吗？然后，AppController可以告诉每个Presenter在给定事件的情况下该做什么。
• ＆＃34; Event Bus＆＃34;似乎是一个准全局变量。但是，如果你能用更精确定义的方法（即AppController在每个Presenter上调用的方法）完成同样的事情，那么这不是更好吗？

更准确地说明我的担忧：为什么要引入一个事件总线，而不是简单地让事件＆＃34;起泡＆＃34;到适当的决策层面？对我而言，这似乎是MVP概念最直接的扩展，并且它不需要事件总线的新概念。我不明白事件总线引入了什么问题需要解决。

Answer 1

事件总线的优点是代码分离。

您可以向公交车点火自定义事件，不再需要关心您的活动。 每个演示者只订阅那些它真正需要知道的事件。这将导致更清晰的代码，因为您不必创建一个必须知道所有演示者的调度程序，以便将事件委托给他们。

在我看来，事件总线是一件非常好的事情，可以使代码清晰易懂。

Answer 2

您提出的方法很好，有一个很大的缺点：当您的应用程序增长时，它会调用意大利面条代码。

This presentation与Android有关，但争论也适用于GWT。

另请参阅Google I / O 2009中的this famous presentation，其中明确谈到使用事件总线来对抗意大利面条代码（必须观看如果您还有已经没过了。

最后，this blog post处理JS中的观察者与中介模式：在GWT中，实现观察者模式通过事件处理程序，而中介模式由事件总线实现。这是 tl; dr ：«在本地使用观察者“，在组件内部，在组件之间”远程“调解。 »