Android：浅谈 mvp-clean 架构

官方示例：todo-mvp-clean

官方对 clean 的解读：the-clean-architecture

mvp-clean 可以认为是对 mvp 的再次分层。不过就我个人而言，我认为 clean 是一种清晰的思想；而 mvp 不是。

对比 mvp-clean 与 mvp 的示例代码会发现，里面多了一个 usecase 的概念。

use case 简单翻译可以认为是“用例”。

用例是什么意思，其实可以有多种理解，因为用例这个词还是有点抽象；对应到示例代码中，用例可以理解成行为，操作数据的行为。

比如在 todo-mvp-clean 有哪些操作数据的行为？查询全部数据，根据id 查询单个数据，更新数据状态（切换成已完成状态/未完成状态）。

好，既然行为确定了，那么就定义对应的用例。代码上的体现就是，定义对应的类，分别去做对应的数据操作。
比如：ActiveTask, GetTasks,ClearCompleteTasks 这些。

这些 usecase 是对 TasksRepository 的进一步封装，可以这么理解。本来TasksRepository已经屏蔽了数据源是来自网络还是本地数据库，所以的数据操作都是 mvp 的 p 去调用TasksRepository去进行的。但是呢，在 clean 架构中，并不会让 p 去直接调用 TasksRepository ，而是，让 p 根据需要分别去调用对应的用例，比如：ActiveTask, GetTasks,ClearCompleteTasks 这些。然后，对TasksRepository的调用，去进行数据操作，是这些用例的内部操作了。

从这个角度看，调用栈大概是这样的一个走向：v <-> p -> usecase -> repository -> local/remote;

为什么 v <-> p 是双向互通的呢？这个在上篇谈 mvp 架构的时候已经做了说明。
上篇链接：浅谈 mvp 架构

然后关于 p v 的地方 mvp-clean 与 mvp 没有任何的区别。可以认为，mvp-clean 对于 mvp 的改变就是多了一个 usecase ，插在了 repository 与 presenter 之间。本来是 p -> r 的，现在变成了 p -> uc -> r .

关于 clean 的 usecase , 我认为是挺好的一种分离逻辑的方式，可测试性更好，代码分离的更彻底。后续有功能的增加或者修改，只要增加对应的 usecase 或者修改对应的 usecase 即可。嗯，还有 repository 应该也要修改。因为按照之前的封装，repository 本质上是为 v 服务的，如果 v 的行为有变化，那么 repository 里面就要做对应的修改了。

对于 mvp 或者 mvp-clean 我认为这两种架构没有做到解耦，但是做到了逻辑分层。如果界面上的行为有修改，那么可能会导致其他的地方都要修改，无论是 p 还是 usecase, repository, local/remote 这些。

虽然修改还是牵一发而动全身的，但是每个地方的职责是确定的，互相之间没有责任的牵扯。

以上。

分析的不到位的地方，希望各位指出。惩前毖后，治病救人。

更多相关文章

随机推荐