Java GWT中事件总线的动机

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

• 有多个面板，每个面板始终可见
• 每个面板都有一个演示者，并且有一个位于所有演示者之上的AppController
• 有些应用程序级事件发生在一个演示者内部，但对其他演示者有影响
• 为此建议的体系结构似乎涉及一个事件总线。然而，我不确定我是否看到了比简单的东西更大的优势
• 特别是，简单地允许AppController（并且仅允许AppController）订阅来自任何演示者的事件不是更干净吗？然后，AppController可以告诉每个演示者在给定事件的情况下要做什么
• “事件总线”似乎是一个准全局变量。但是，如果您可以使用更精确定义的方法（即AppController对每个演示者调用的方法）完成同样的事情，这不是更好吗

---

更准确地说，我的担忧是：为什么要引入事件总线，而不是简单地让事件“冒泡”到适当的决策级别？对我来说，这似乎是MVP概念最直接的扩展，它不需要事件总线的新概念。我不明白引入事件总线是为了解决什么问题。

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

您可以将自定义事件发送到总线，而不必再关心您的事件。 每个演示者只订阅该活动，这是他们真正需要知道的。这将导致代码更清晰，因为您不必创建一个调度器，它必须知道所有演示者才能将事件委派给他们

---

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

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

是关于Android的，但GWT的观点也成立

另请参见Google I/O 2009，其中明确提到使用事件总线来对抗意大利面代码（如果您还没有看到，这是一个必须关注的问题）

---

最后，讨论JS中的观察者与中介者模式：在GWT中，观察者模式由事件处理程序实现，而中介者模式由事件总线实现。这是tl；dr:«在组件内部“本地”使用观察者，在组件之间“远程”使用中介。»

我发现MVP的GWT文档令人困惑。你可以在这里找到它——SSR——谢谢。我确实读过这个文档，但有趣的是，文档中并没有给出事件总线的真正动机。它只是说“你需要依靠一个事件总线”，这并不能真正澄清问题。谢谢，这很有帮助。然而，至少在谷歌I/O演示文稿的PDF版本中（我在埃塞俄比亚，所以我没有足够的带宽观看视频），所描述的事件总线的替代方案似乎是直接演示者对演示者的交流，我同意这种交流变成了意大利面。我试图描述的并不是这样——而是一种情况，在这种情况下，仍然有一个“中介”或“代理”来隐藏演示者，但这个中介是一个逻辑（AppController），它位于所有演示者的“顶部”。感谢您的回复。当你说替代方案是“创建一个调度器”时，我有点不清楚你指的是什么。你是说每个演示者中都有一个调度员，它必须知道所有其他（订阅的）演示者的情况吗？我同意这听起来很糟糕。相反，我的意思是AppController接收应用程序事件，然后简单地告诉演示者做一些事情（使用演示者中定义的公共方法）。在此方案中，演示者不收听来自其他演示者的事件。如果我遗漏了什么，请道歉……如果您只有几个演示者，这种方法将有效。但是，如果你想在一个更大的范围内，让我们说超过20-100个演示者，你将不得不在这个单一的AppController中有更多的逻辑。事实上，这个类需要知道所有的演示者，并且必须在那里调度事件。如果向演示者添加自定义事件，则还必须更新AppController。好的，这听起来是一个很好的理由。谢谢你的澄清。