构建客户端摇摆应用程序应该在总线上通知什么（应用程序范围的消息系统，在概念上类似于 JMS，但要简单得多）以及应该使用直接侦听器通知什么？
乘坐公共汽车时，我总有一种无法回避的感觉“我不知道谁在哪里使用它”。此外，没有固定的顺序，很难否决事件，很难确切地知道在固定的时间发生了什么。
另一方面，使用监听器意味着要么直接引用源对象（耦合），要么通过无数次转换传递引用（A--b_listener-->B，B--c_listener-->C，只是因为 a 只需要知道一些东西C可以说，但B没有兴趣）。
那么，这方面有什么经验法则吗？有什么建议如何平衡吗？
以我的经验，试图让 Swing 做一些它不是为或不希望你做的事情，是非常痛苦的。
我会选择最简单的方法；保持你的代码干净，用“Swing Way”做，直到你开始看到问题。
事件总线是在某些架构中提供解耦的非常非常有用的工具。侦听器很容易实现，但是当您的对象和依赖图变得很大时，它们会受到很大的限制。侦听器往往会遇到循环依赖的问题（事件可能以奇怪的方式“反弹”，你最终不得不玩游戏以确保你不会被卡住。大多数绑定框架都会为你做到这一点，但有些令人反感知道侦听器事件正在发射到一百万个地方）。
我根据项目规模和可扩展性做出这种决定。如果它是一个大型应用程序，或者应用程序的某些方面可以通过动态方式（如插件模块等），那么总线是保持架构清洁的好方法（类似 OSGI 的模块容器是另一种方法，但是较重的重量）。
如果您正在考虑总线架构，我建议您查看Event Bus项目 - 它与 Swing 配合得非常好，并为您所询问的内容提供了一个健壮的、开箱即用的解决方案。
Java Swing 中的约定是大量使用侦听器。坚持约定可以提高可维护性，但会扼杀创新。
我没有在 Swing 中遇到过总线方法，但我觉得它很有趣。
好吧，我可以想象使用类似系统的 BUS 更新模型并使用侦听器委托来自模型的事件的方法。简单的场景：我得到了代表数据生产者的服务器端。然后在客户端有一个消费者接口，它消耗所有传入的消息并将它们转换为我的内部消息/DTO，并将它们推送到总线中，总线将它们分配到应用程序模型中。这些模型处理传入的消息并决定使用侦听器通知感兴趣的组件。