android - 在 Dagger/MVP 应用程序中放置业务逻辑的位置

Question

看过很多 Dagger 演示应用后，我不清楚业务对象的放置位置。在典型的三层应用程序中，您有用户界面、业务层和数据访问层。 MVP 本质上是一个三层架构。

Dagger 处理组件和模块，我已经看到演示应用程序将业务逻辑放在模块中。但是根据 MVP 架构，业务逻辑属于 Presenter 层，因为该层被假设为 ui 和模型之间的桥梁。许多这些演示应用程序的模型仅包含一个类，其中包含用于存储和检索数据的公共(public)字段。

有人可以阐明应该这样做的正确方法吗。

Answer 1

按照 Uncle Bob 描述的干净架构，所有包含业务(域)逻辑(规则)的代码都应该在业务层内。
例如，我们正在开发在线订购食物/衣服的移动应用程序。不要紧。

表示层:(由view和presenter组成)

- Presenter - 处理 View Intent (按钮点击、 View 呈现等)，调用业务交互器，在收到交互器的结果后，说要查看以呈现屏幕/布局的当前状态。
- View - 只不过是渲染 UI，保持 view 愚蠢，你所有的 view 逻辑都应该在 presenter 中。

示例: 在这一层中，您可以检查例如:用户操作的购物车屏幕，您的表示层向返 repo 物车项目的交互器发出请求。如果列表为空，您的 View 将显示标题为“您的卡为空”的布局，否则显示项目列表。

业务/领域层:(由交互器、辅助类等组成)

第一条规则是保持域层纯净。如果您使用 gradle，则可以使用具有空依赖项的多模块。只有语言，rxjava 因为它几乎是我们这个时代的标准。

示例:您需要验证用户订单信息(送货地址、姓名首字母)。你所有的逻辑都应该在这里。长度检查、正则表达式验证等

数据层:

知道如何保存、获取、更新、删除信息。所有关于坚持。在android情况下:数据层可以通过retrofit2、room orm等发出http请求。缓存从这里开始。

如果您的应用不包含很多业务规则，您可以避开业务层。这取决于项目。

使用 SOLID 原则也很重要。它将使您的架构易于理解、灵活和可维护。阅读更多 here .