客户端Swing应用程序中的总线或监听器/代理？

Question

构建客户端swing应用程序应该在总线上通知什么（应用程序范围的消息系统，在概念上类似于JMS但更简单）以及应该使用直接侦听器通知什么？

当使用公共汽车时，我总是有一种难以理解的感觉：“我不知道是谁使用了那个和哪里”。此外，没有订单，难以否决事件，很难确切知道在设定的时间发生了什么。

另一方面，使用侦听器意味着直接引用源对象（耦合）或通过无数次转换传递引用（A - b_listener - ＆gt; B，B - c_listener - ＆gt; C仅因为a需要知道只有C可以告诉的东西，但B对此毫无兴趣。

那么，有没有关于此的拇指规则？有什么建议如何平衡？

Answer 1

根据我的经验，试图让Swing做一些不是为了或不想让你做的事情，是非常痛苦的。

我会选择最简单的方法;保持你的代码干净，做“摇摆方式”直到你开始看到问题。

Answer 2

事件总线是非常非常有用的工具，用于在某些体系结构中提供解耦。监听器易于实现，但是当对象和依赖关系图变大时，它们会有很大的局限性。听众倾向于遇到循环依赖的问题（事件可以以奇怪的方式'反弹'，你最终必须玩游戏以确保你不被卡住。大多数绑定框架为你做这个，但是有一些令人反感的事情知道听众的事件正在拍摄到一百万个地方。）

我根据项目规模和可扩展性做出这种决定。如果它是一个大应用程序，或者应用程序的某些方面可以通过动态（如插件模块等等），那么总线是保持架构清洁的好方法（类似OSGI的模块容器是另一种方法，但是更重的）。

如果您正在考虑总线架构，我建议您查看Event Bus项目 - 它与Swing配合得很好，并为您提出的解决方案提供了一个强大的，开箱即用的解决方案。

Answer 3

Java Swing中的约定是大量使用侦听器。遵守惯例可提高可维护性，但会扼杀创新。

我没有在Swing中遇到过总线方法，但我发现它很有趣。

Answer 4

好吧，我可以想象使用类似BUS系统更新模型的方法，并使用侦听器委托模型中的事件。简单场景：我得到了代表数据生产者的服务器端。然后在客户端获得一个消费者界面，它消耗所有传入的消息并将它们转换成我的内部消息/ DTO并将它们推送到总线中，然后将它们分配到应用程序模型中。这些模型处理传入消息并决定使用侦听器通知感兴趣的组件。