看过很多Dagger演示应用程序后，我不清楚在哪里放置业务对象。在典型的三层应用程序中，您具有ui，业务层和数据访问层。 MVP本质上是一个三层体系结构。
Dagger处理组件和模块，我已经看到演示应用程序将业务逻辑放置在模块中。但是根据MVP架构，业务逻辑属于Presenter层，因为该层假定充当ui和模型之间的桥梁。这些演示应用程序中的许多应用程序都具有仅由带有公共字段的类组成的模型来存储和检索数据。
有人可以澄清应该做的正确方法吗？
答案 0 :(得分：3)
在遵循Bob叔叔描述的简洁架构之后，所有包含业务（域）逻辑（规则）的代码都应位于业务层内部。
例如，我们正在开发用于在线订购食物/衣服的移动应用程序。没关系。
演示层：（由视图和演示者组成）
-演示者-处理视图意图（单击按钮，渲染视图等），在收到来自交互器的结果后，致电业务交互器，表示要渲染屏幕/布局的当前状态。
-视图-只是呈现UI，保持视图愚蠢，所有视图逻辑都应在Presenter中。
示例案例：在该层中，您可以检查例如：用户选择了购物车屏幕，您的表示层向交互器发出请求，该交互器返回购物车项目。如果列表为空，则视图显示标题为“您的卡为空”的布局，否则显示项目列表。
业务/域层 ：（由 interactor ，助手类等组成）
第一个规则是保持域层纯净。如果使用gradle，则可以使用具有空依赖项的多项目。仅语言，rxjava导致它几乎是我们时代的标准。
示例案例：您需要验证用户订单信息（送货地址，首字母缩写）。您所有的逻辑都应该在这里。长度检查，正则表达式验证等。
数据层：
知道如何保存，获取，更新，删除信息。关于持久性。在android系统中：数据层可以通过retrofit2，room orm等发出HTTP请求。缓存从此处开始。
如果您的应用程序不包含很多业务规则，则可以避免业务层。这取决于项目。
使用SOLID原理也很重要。这将使您的体系结构易于理解，灵活且可维护。了解更多here。