Andorid项目架构篇----MVP + Clean Architecture

最新推荐文章于 2024-08-10 08:03:13 发布

☆☆张

最新推荐文章于 2024-08-10 08:03:13 发布

阅读量301

点赞数 2

分类专栏： Android技术学习

3 篇文章 0 订阅

订阅专栏

这一篇的例子，是基于Clean Architecture原则。

它是基于上一篇最最简单的MVP 架构demo，在表现层和存储库之间，添加了域层（domain ），将app分为3层：

大概看了下，就是总结了常用的系统架构思想，比如：

这里呢，将系统分为4个同心圈：

The Dependency Rule 依赖规则，这是最重要的原则，这条规则说源代码依赖关系只能指向内部。也就是高内聚低耦合。圆圈内部和外部的分离，双方的改变互不影响。
Entities 实体类（这个像JavaBean类），封装企业范围的业务规则，也就是最通用的规则，可以是一个带方法的object对象，或者一个数据，一组数据结构，一个方法。可以在企业不用应用间复用。任何操作的变化，都不应该改变实体层（Entities ）
Use Cases 用例，这一层是特定的业务逻辑。它封装和实现了系统的所有用例。使用Entities 实体类来实现特定的业务逻辑。这层的改变，不会影响Entities 层，也不会受到database,UI, 或者其他通用框架的变化的影响。当然，应用的操作的变化，会影响到用例的变化。
Interface Adapters 接口适配器，将Entities或者Use Cases与其他外部持久层框架的数据转换（Database ，Web等）。这层包含一个GUI的完整MVC架构。 Presenters，Views ，Controllers 都属于这一层。
Frameworks and Drivers 框架和驱动，最外层，通常是Database, Web Framework等
Crossing boundaries. 跨越边界，不同层的交流吧，通常使用“依赖倒置原则”。为了不违反依赖规则，内部圆和外部圆不能直接调用，所以一般可以通过集成接口，接口调用来通信。还有个类似的方法，多态。

好了，继续回到MVP+Clean Architecture

首先知道三个概念：

MVP：上篇最基础的项目中的 Model View Presenter 模型。
Domain：包含所有业务逻辑。域层主要以用例（use cases）或交互（interactors ）。这些用例提供了开发者所有能执行的来自展示层的行为。
Repository：最基础的项目中的存储库。