我正在创建一个Android应用程序，并希望遵守干净的架构。例如，我有一个活动，它有一个创建用例的演示者。在那个内层，我有一个存储库接口（用例已知），它由一个具体的存储库实现，我们称之为repsoitoryImpl（用例不知道）。我在之前的项目中所做的是在活动中创建演示者和repositoryImpl，并将repositoryImpl作为存储库传递给演示者。然后，只要有来自活动的动作（例如，按下按钮），演示者就可以创建新的用例并将存储库传递给它。
这是有效的，但是a）用例的构造函数可以变得非常长并且b）UI具有所有其他“外部”事物的知识，例如， repositoryImpl。所以我认为DI救援！并开始尝试Dagger 2.然而，我目前的解决方案似乎并不“正确”。我本来希望的是，我可以在一个用例中有一个@inject注释的存储库，并注入repositoryImpl。但是我发现，在“注射链”的开头，我必须在匕首组件上调用inject（）。在大多数示例中，这是在活动中完成的。但是，我必须将活动中的演示者和用例注入演示者，以便能够将内容注入用例。它是否正确？问题是我想用不同的参数动态创建用例而不是注入它们。
所以我目前的解决方案是将匕首“AppComponent”作为Android Application类中的静态字段，然后在我调用的用例中
Application.component.inject(this)
这允许我在用例中注入东西。但随后用例依赖于匕首，这不符合清洁架构。因为框架依赖性应该只出现在外层。
这个问题有一个共同的解决方案吗？我理解错了吗？
正如您在清洁体系结构中已经指出的那样，用例必须不了解DI框架 - 即使用框架特定属性来装饰用例也是一种气味。
正如这里所讨论的：How to handle UseCase Interactor constructors that have too many dependency parameters in DDD w/ Clean Architecture?具有太多的构造函数参数通常是用例“做得太多”的指示。你应该考虑分裂它们。
此外，用例访问“详细信息”（存储库，外部服务和系统）的接口应该以对用例最方便的方式设计。这意味着不是将多个存储库接口和多个服务接口传递给用例，您可以考虑使用façade模式并设计一个或两个接口，这些接口更方便用于使用不同存储库/服务“聚合”工作的用例。这也将减少传递给构造函数的参数数量。
根据清洁的架构，你应用程序的“组成”发生在“主要组件” - 一个生活在框架圈子里的类。有对象被创建和注入。如果你想动态创建用例，你可以有一个工厂模式。