2

我正在创建一个 Android 应用程序并希望遵守干净的架构。例如，我有一个活动，它有一个创建用例的演示者。在那个内层，我有一个存储库接口（由用例知道），它由一个具体的存储库实现，我们称之为 repsoitoryImpl（用例不知道）。我在之前的项目中所做的就是在activity中创建presenter和repositoryImpl，并将repositoryImpl作为repository传递给presenter。然后，只要有来自活动的动作（例如按下按钮），演示者就可以创建一个新的用例并将存储库传递给它。

这可行，但是 a) 用例的构造函数可能会变得很长 b) UI 了解所有其他“外部”事物，例如 repositoryImpl。所以我想DI来救援！并开始尝试 Dagger 2。但是，我目前的解决方案似乎并不“正确”。我想要的是我可以在一个用例中拥有一个带有@inject 注释的存储库，并且一个repositoryImpl 被注入。但是我发现，在“注入链”的开头，我必须在匕首组件上调用 inject() 。在大多数示例中，这是在活动中完成的。但是随后我必须将演示者注入活动中，并将用例注入演示者，以便能够将内容注入用例。这个对吗？问题是我想用不同的参数动态创建用例而不是注入它们。

所以我目前的解决方案是将匕首“AppComponent”作为Android应用程序类中的静态字段，然后在我的用例中调用

Application.component.inject(this)

这允许我在用例中注入东西。但是随后用例依赖于不符合干净架构的匕首。因为框架依赖应该只出现在外层。

这个问题有一个通用的解决方案吗？我理解错了吗？

4

1 回答 1

3

正如您在干净的架构用例中已经指出的那样，一定不能了解 DI 框架——即使用框架特定属性装饰用例也是一种气味。

正如这里所讨论的：如何在 DDD w/ Clean Architecture 中处理具有太多依赖参数的 UseCase Interactor 构造函数？有太多的构造函数参数通常表明用例“做得太多”。你应该考虑拆分它们。

此外，用例用来访问“细节”（存储库、外部服务和系统）的接口应该以最方便用例的方式设计。这意味着您可以考虑使用外观模式并设计一两个更方便用例的接口，而不是将多个存储库接口和多个服务接口传递给用例，然后将工作与不同的存储库/服务“聚合” . 这也将减少传递给构造函数的参数数量。

根据干净的架构，您的应用程序的“组合”发生在“主要组件”中 - 一个生活在框架圈子中的类。有对象被创建和注入。如果你想动态创建用例，你可以有一个工厂模式。

于 2018-03-03T05:46:44.697 回答