我假设你熟悉MVP和事件驱动模式。
据我所知,MVP和事件驱动模式都是为负责任地分离和提高可读性而设计的。但是使用事件总线之类的库可以更容易地实现事件驱动。
我的问题是,如果您可以使用事件和订阅者模式来分离您的方法职责,那么将您的应用程序架构更改为MVP有什么好处?
我问题的第二部分是将事件库(如Eventbus)与MVP模式一起使用的可行性。
发布于 2016-06-16 17:54:20
事件驱动架构是用于通信的。您可以使用它在应用程序中松散耦合的组件之间传输消息/事件。Benefit:您摆脱了添加/删除组件的头疼问题,即删除订阅者而不修改发布者等等。
MVP用于构建应用程序逻辑。它帮助您将业务逻辑远离GUI,并引入Presenter作为处理View上的事件的中间人,涉及到适当的Model来处理与每个View的事件相对应的业务逻辑,并将数据格式化到View。Benefit:它划分了UI逻辑和业务逻辑之间的界限,允许您在没有任何具体UI内容的情况下测试业务逻辑甚至这两种逻辑。
现在是第一部分:由于最关心的是如何组合应用程序逻辑以及如何确保逻辑在应用程序中得到很好的实现(单元测试),MV*可以帮助你,而不是EventBus。
第二部分:是的,你可以将EventBus/MessageBus和MVP一起使用,因为它们负责不同的事情。例如,您使用MVP将片段构建为View、Presenter和Model,并使用EventBus/MessageBus实现片段与应用程序中的其他活动片段之间的通信。
这里有一个同时提供MessageBus和MVP的实际框架:http://robo-creative.github.io/mvp。如果您想了解如何将它们结合在一起,请阅读以下指南:http://robo-creative.github.io/mvp/presenter-features.html
发布于 2016-06-14 05:32:43
编辑:已将其清理并缩短。
我不认为事件驱动架构和MVC架构的好处是相互排斥的,正如你的问题所暗示的那样。您可以设计既是事件驱动的,又与MVC体系结构一致的代码。
事件驱动意味着您拥有在特定事件发生时执行的事件处理程序。事件开始于较低的级别(鼠标运动和键盘运动),然后通过工具包向上传递到较高级别的处理程序。MVC关心的是如何组织处理程序的位置,以及它们如何与业务逻辑交互。
那么回到EventBus吧。如果您通过EventBus指向所有的UI事件,并且对模型的所有更改依次通过Eventbus传递回视图,那么我认为EventBus库构成了您的MVC架构中控制器的重要部分。
当我考虑MVC时,我的目标是将业务逻辑和数据从数据的表示中解耦。像Eventbus这样的东西可以帮助你做到这一点。您的控制器类将把您的模型绑定到EventBus,并将UI插入到另一端。当你这样做的时候,你的模型只知道它得到了一个事件流。它不知道事件流是由GUI、测试设备还是硬件调试器提供的。
https://stackoverflow.com/questions/37798826
复制相似问题