为什么我不应该使用消息总线而不是加载器和服务？

Question

在典型的Android项目中,我们需要以干净的方式将数据从某个地方(REST,SQL,缓存等)提取到UI中,我们通常使用Loader,Service或(可能是yuk)AsyncTask,但我发现所有这些方法由于以下几个原因不满意:

• 它们很难看,尤其是具有令人震惊的API结构的Loaders
• 它很容易被包裹在线程中,并踩在UI线程上
• 我们的表示层代码被Android代码和样板文件污染了.我们经常将Android对象(例如Cursors)传递到UI层,这使得一个干净的架构几乎无法实现.这迫使我们将业务领域特定代码(理想情况下是普通的Java对象)与Android平台代码混合在一起 - 对于未来开发的可读性,维护,测试或灵活性来说并不是很好.在实践中,我们经常会遇到庞大,混乱的Activity/Fragment类.

我被这些文章中概述的想法所吸引:http : //fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ http://antonioleiva.com/mvp-android/ http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

成功开始使用MVP将活动/碎片/视图分解为更小/更清洁的部分,我现在认为上述问题的解决方案可能是依赖于消息总线(Otto,EventBus等)而不是服务或加载器或任何与域数据交互的内容.

所以在实践中这意味着不是使用(例如)CursorLoader从数据库加载Cursor,而是使用消息总线发送消息来请求数据,数据被加载到后台线程以响应该消息,然后通过UI线程上的消息到达时处理响应数据.对我来说至关重要的是,我希望将数据结构从业务领域推出,而不是Android域,所以我更喜欢业务对象数组,而不是Cursor.

这是工程设计,总是需要权衡,虽然这似乎提供了更清晰的关注点分离,但是装载机/服务模板的减少,缺点是什么？

• 理解代码可能更难(特别是对于新开发人员而言)
• 有必要确保在正确的线程上发送和接收消息(Otto似乎在这里可能有限制)
• 有必要避免将一切事物作为一种信息实施的诱惑,这最终会适得其反
• 传递业务对象集合可能不如使用像Cursors这样的对象.虽然在许多情况下它在实践中是一个问题吗？
• 我不知道Otto/EventBus是否只是为了传递非常小的消息,或者是否适合传递更大的对象(例如业务对象数组).

我的问题是,是否有任何基本原因不采用这种基于消息的Android应用程序方法？

Answer 1

他们对自己对此类方法的抵制提供了解释：

1. 小心代码抽象。

2. 避免依赖注入框架。

3. 避免创建不必要的对象。

4. 避免内部 Getter/Setter。