我假设您熟悉 MVP 和事件驱动模式。
据我所知，MVP 和事件驱动模式都旨在负责任地分离并提高可读性。但是使用像事件总线这样的库可以更容易地实现事件驱动。
我的问题是，如果您可以使用事件和订阅者模式分离方法职责，那么将应用程序架构更改为 MVP 有什么好处？
我的问题的第二部分是使用事件库（如 Eventbus）和 MVP 模式的可行性。
【问题讨论】：
标签： java android design-patterns architecture
事件驱动架构用于通信。您可以使用它在应用程序中松散耦合的组件之间传输消息/事件。 好处：您摆脱了添加/删除组件的麻烦，即在不修改发布者的情况下删除订阅者等等。
MVP 用于构建应用程序逻辑。它可以帮助您使业务逻辑远离 GUI，并引入 Presenter 作为处理 View 事件的中间人，涉及适当的 Model 来处理与每个 View 事件对应的业务逻辑，并将数据格式化到 View。 好处：它划定了 UI 逻辑和业务逻辑之间的界限，允许您在没有任何具体 UI 内容的情况下测试业务逻辑甚至两种逻辑。
现在是第一部分：由于最关心的是如何编写应用程序逻辑以及如何确保逻辑在应用程序中很好地实现（单元测试），MV* 可以帮助您，而不是 EventBus。
第二部分：是的，您可以将 EventBus/MessageBus 与 MVP 一起使用，因为它们负责不同的事情。例如，您使用 MVP 将 Fragment 构建为 View、Presenter 和 Model，并使用 EventBus/MessageBus 来实现您的 Fragment 与您应用中的其他 Activity、Fragment 之间的通信。
提供 MessageBus 和 MVP 的实际框架在这里：http://robo-creative.github.io/mvp。如果您想了解如何将它们结合起来，请阅读以下指南：http://robo-creative.github.io/mvp/presenter-features.html
【讨论】：
编辑：清理并缩短它。
我认为事件驱动架构和 MVC 架构的好处并不像您的问题所暗示的那样相互排斥。您可以设计既是事件驱动又与 MVC 架构一致的代码。
事件驱动意味着您拥有在某些事件发生时执行的事件处理程序。事件从低级别开始（鼠标动作和键盘动作）并通过工具包向上渗透到更高级别的处理程序。 MVC 关注您如何组织处理程序的位置以及它们如何与业务逻辑交互。
所以回到 EventBus。如果您通过 EventBus 指向所有 UI 事件，并且对模型的所有更改又通过 Eventbus 传递回视图，那么我会说 EventBus 库构成了 MVC 架构中控制器的重要部分。
当我想到 MVC 时，我的目标是将业务逻辑和数据与数据表示分离。像 Eventbus 这样的东西可以帮助你做到这一点。您的控制器类将把您的模型绑定到 EventBus，并将 UI 插入另一侧。当你完成后，你的模型只知道它被赋予了一个事件流。它不知道事件流是由 GUI、测试设备还是硬件调试器提供的。
【讨论】：