MVP- architecture翻译

原文地址 ：https://github.com/googlesamples/android-architecture/tree/todo-mvp-clean/
翻译 ： leo

总结

MVP clean architecture 是基于Clean Architecture.的准则的观点

基于MVP sample。添加了 domain layer 介于 presentation 和 repositories。同时也将整个app 分为三个层次处理

如下图所示

• MVP: model view Presenter 设计准则
• Domain : 处理所有的业务逻辑，注意是所有的业务逻辑。domain层是以presentation layer 层的use cases 或者 interactors 开始的。
• Repository: 获取数据，以及数据的存储

概念

mvp-clean 和 基本的mvp 最大的区别就是在domain层和use cases 的使用上。从 presenters 层分离出domain 层好处是可以减少代码的冗余（例Task filters.
Use case 定义了 app 所需的操作。这增加了 可阅读性，因为类的名称使目的更加的明显。（例tasks/domain/usecase/）

Use case 的好处是在domain的代码层上可以复用。CompleteTask在TaskDetailPresenter和TasksPresenter做到了很好的复用。
use cases 是使用command pattern在后台完成操作的。domain layer 是完全解耦与Android 层和第三方依赖的。是一个纯java层的处理

Issues/notes

Use cases 从主线程剥离出来，对于Android app是个好的操作。这种操作是尽可能的减少占用UI 线程。我们决定使用 command pattern 将use case 在线程池里执行操作。同样的我们可以用RxJava 或者 Promises实现同样的功能。

我们使用异步的repositories 。 但是现在没有必要这么做了。因为use case 已经从主线程里剥离出来了。这是尽量保持 samples 和原来的是一致的。

我们建议为 View,domain 和 APi layers 建立不同的 models 。 但是在这种情况下所有的models 是不可以改变的，因此没有去复制他们。如果一个 View models 包含了和Android 相关的代码。我们需要用两个 models 。一个用于 domain 。一个用于View和一个对应的class 能够在他们之间转换 。

Callbacks 的onError方法在 app 上需要包含具体的错误信息。

测试

通过这样的接口，所有的 domain 代码都可以用于单元测试 。 这个也可以结合整体测试。这个包括所使用的 Use Cases 对应的 view 和 repository.

特性

---

复杂的事情简单化

很简单，虽然代码比之前会多点，但是维护任务也更加的简单