【译】更清晰的Android应用架构-MVP

原文链接：Architecting Android…The clean way?

在过去的几个月中我与公司Tuenti的@pedro_g_s和@flipper83（两位android技术大牛）两位同事讨论Android应用架构，我决定抽出一点时间写一篇关于Android应用架构的文章。

通过我过去几个月的学习和实践总结了一些方法，它们将向你展示如何去实现这种清晰的Android架构。

开始前的一些准备

我们知道开发一个高质量的软件是非常困难和复杂的，它不仅是为了满足功能实现，也应该是健壮、易维护、易测试和适于伸缩构建。这就是“清晰架构”的由来，这可能是开发任意软件程序的最好方法。

“清晰架构”的概念很简单，产品系统中遵循一系列的习惯原则：

1、与框架分离

2、易测试

3、与UI分离

4、与数据库分离

5、与其它外部组件分离

上图中你所看见的不一定非要4个圆环来表示，因为这只是原理图但你应该考虑到相关规则

源码依赖只能指向内环而内环不能知道它所在外环的任何事情。

下面的一些术语可以让你明白和了解这是种非常好的架构方式：

实体：他们是程序的业务对象

用例：他们是链接数据流和实体间的纽带，也可叫作Interactor(翻译成：交互器和耦合器，感觉都不对)

接口适配器：这些适配器为用例和实体提供相应格式的数据。Presenter（展现层）和Controller（控制层）都奴属于这里。

框架和驱动：这里是所有的具体实现，如：界面，工具类，框架等等

更加详尽的解释参见这篇文章The Clean Architecture和视频Robert C. Martin - Clean Architecture （貌似需要翻墙）

我们的方案

我们将从一个简单的案例开始：简单的创建一个app，这个app显示一个从云端取回的朋友或用户数据，当单击列表中的任意一个条目时，然后打开一个新的窗口显示这个用户的具体细节。

给你们看一个视频，你们就知道我讲的什么：Clean Architecture on Android - Sample App （需要翻墙）

Android架构

遵循“关注分离”的原则来让内环的业务操作不知道外环的一切，不依赖任何外部元素所以他们易于测试。

要做到这一点，“我的建议是将这个项目分离成3个不同的层”，这样每个层只关心自己的目标和工作以至独立于其它层。

值得一提的是，每个层只使用它自己的数据模块来达到独立性（你将在代码中见到那个 data mapper被用来实现数据转换，如果你不在整个应用中跨模块使用只需小的代价）

这儿是一个我建议的三层模式：

注意：我没有使用任何第三方库（除了解析json数据的GSON、用于测试的junit，mockito、robolectri、espresso）这是为了使这个示例更加整洁。在你的开发中，无论如何不要犹豫去添加你所熟悉的存储数据的ORMs框架、依赖注入框架、任何工具、第三方库，这样在编写整个示例过程中可以省掉不少功夫（记住：重复造轮子不是个好习惯）。

展现层（Presentation Layer）

这儿是视图和动画相关逻辑呈现的地方，它就是 Model View Presenter模式的一部分(参见：MVP)，但你可以使用其它模式像MVC或MVVM。我不会进一步阐述他们，但这里的Fragments 与Activities仅仅是一个Views，这里不会有逻辑存在于UI逻辑中，并且这里是视图渲染填充的地方。这层中的Presenters结合interactors (用例)在UI线程之外的新线程中执行任务随后使用回调函数传参的形式来渲染视图。

如果你想要一个很酷的MVP和MVVM使用例子，你可以查看我朋友Pedro Gómez的Effective Android UI。

领域层（Domain Layer）

这里是业务规则：所有逻辑发生在这层. 对于Android 项目你也会在这里见到所有的interactors（用例）实现。

这层是一个纯java模块而不是其它Android依赖。所有外部组件使用接口连接业务对象

数据层（Data Layer）

应用需要的所有数据都来自这层，通过一个UserRepository实现（这个接口在领域层），它使用一个Repository Pattern和一个策略相结合，通过一个工厂，依赖某些条件来获取不同的数据源。例如通过一个id来获取用户，随后获取该用户在磁盘上的缓存数据，如果该用户存在的话，否则将从云端检索数据随后保存在磁盘缓存中。

这个背后的理念是所有数据对于客户端来说都是透明的，它并不关心来自内存、磁盘、还是云端的数据是怎样传递和获取的。

注意：我的代码实现非常简单，使用文件系统和Android Preferences作为磁盘缓存，这是为了达到学习的目的。重申：如果已有第三方库能胜任这种工作就不要重复的造轮子。

错误处理（Error Handling）

这总是一个值得讨论的话题，如果你有更好的解决方案请共享在这儿。

我的策略是使用回调接口，以数据存储响应为例，回调接口中有onResponse()和onError()两个方法。这里封装了一个叫“ErrorBundle”异常处理类：这种方法也带来一些困难，因为这儿是一个回调链直接将错误抛给展现层（Presentation Layer）。代码可读性不太好。

另外，我的主张是实现一个事件总线系统去抛事件当某些错误发生时，但这类似使用GOTO。当你订阅几个事件时，如果你不善于控制处理它们，你会感到很困惑。