在 Dagger/MVP 应用中放置业务逻辑的位置
Where to place business logic in a Dagger/MVP app
看过很多 Dagger 演示应用后，我不清楚业务对象的放置位置。在典型的三层应用程序中，您有 ui、业务层和数据访问层。 MVP 本质上是一个三层架构。
Dagger 处理组件和模块，我已经看到演示应用程序将业务逻辑放在模块中。但是根据 MVP 架构，业务逻辑属于 Presenter 层，因为该层被假设为 ui 和模型之间的桥梁。许多这些演示应用程序的模型仅包含 class 和 public 字段以存储和检索数据。
谁能阐明应该这样做的正确方法。
按照 Uncle Bob 描述的干净架构，所有包含业务（域）逻辑（规则）的代码都应该在业务层内。
例如，我们正在开发在线订购食物/衣服的移动应用程序。不要紧。
表示层：（由 view 和 presenter 组成）
- Presenter - 处理视图意图（按钮点击、视图呈现等），调用业务交互器，在从交互器收到结果后，说要查看以呈现屏幕/布局的当前状态。
- View - 只不过是渲染 UI，保持视图愚蠢，你所有的视图逻辑都应该在 presenter 中。
示例： 在这一层中，您可以检查例如：用户操作的购物车屏幕，您的表示层向交互器发出 returns 购物车商品的请求。如果列表为空，您的视图将显示标题为“您的卡片为空”的布局，否则显示项目列表。
业务/领域层：（由interactor、helper类等组成）
第一条规则 是保持域层纯净。如果您使用 gradle，则可以使用 multi-modules 和空依赖项。只有语言，rxjava 因为它几乎是我们这个时代的标准。
示例：您需要验证用户订单信息（送货地址、首字母）。你所有的逻辑都应该在这里。长度检查、正则表达式验证等
数据层：
知道如何保存、获取、更新、删除信息。所有关于坚持。在 android 情况下：数据层可以通过 retrofit2、room orm 等发出 http 请求。缓存从这里开始。
如果您的应用不包含很多业务规则，您可以避开业务层。这取决于项目。
使用 SOLID 原则也很重要。它将使您的架构易于理解、灵活和可维护。阅读更多 here.
看过很多 Dagger 演示应用后，我不清楚业务对象的放置位置。在典型的三层应用程序中，您有 ui、业务层和数据访问层。 MVP 本质上是一个三层架构。
Dagger 处理组件和模块，我已经看到演示应用程序将业务逻辑放在模块中。但是根据 MVP 架构，业务逻辑属于 Presenter 层，因为该层被假设为 ui 和模型之间的桥梁。许多这些演示应用程序的模型仅包含 class 和 public 字段以存储和检索数据。
谁能阐明应该这样做的正确方法。
按照 Uncle Bob 描述的干净架构，所有包含业务（域）逻辑（规则）的代码都应该在业务层内。
例如，我们正在开发在线订购食物/衣服的移动应用程序。不要紧。
表示层：（由 view 和 presenter 组成）
- Presenter - 处理视图意图（按钮点击、视图呈现等），调用业务交互器，在从交互器收到结果后，说要查看以呈现屏幕/布局的当前状态。
- View - 只不过是渲染 UI，保持视图愚蠢，你所有的视图逻辑都应该在 presenter 中。
示例： 在这一层中，您可以检查例如：用户操作的购物车屏幕，您的表示层向交互器发出 returns 购物车商品的请求。如果列表为空，您的视图将显示标题为“您的卡片为空”的布局，否则显示项目列表。
业务/领域层：（由interactor、helper类等组成）
第一条规则 是保持域层纯净。如果您使用 gradle，则可以使用 multi-modules 和空依赖项。只有语言，rxjava 因为它几乎是我们这个时代的标准。
示例：您需要验证用户订单信息（送货地址、首字母）。你所有的逻辑都应该在这里。长度检查、正则表达式验证等
数据层：
知道如何保存、获取、更新、删除信息。所有关于坚持。在 android 情况下：数据层可以通过 retrofit2、room orm 等发出 http 请求。缓存从这里开始。
如果您的应用不包含很多业务规则，您可以避开业务层。这取决于项目。
使用 SOLID 原则也很重要。它将使您的架构易于理解、灵活和可维护。阅读更多 here.