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

Question

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

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

有人能澄清一下应该做的正确方法吗？

Answer 1

遵循鲍勃叔叔描述的干净架构，您所有包含业务（域）逻辑（规则）的代码都应该在业务层内。
例如，我们正在开发用于在线订购食物/衣服的移动应用程序。没关系。

Presentation Layer：（由view和presenter组成）

- Presenter strong> - 处理视图意图（按钮点击、视图渲染等），调用业务交互器，在收到交互器的结果后，表示要查看以呈现屏幕/布局的当前状态。
- 查看 - 无非是渲染 UI，保持视图愚蠢，所有视图逻辑都应该在演示器中。

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

业务/领域层：（由交互器、助手类等组成）

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

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

数据层：

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

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

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