在我的域层中,我有合同Hashing
。我的域名服务之一取决于此合同。目前,我已将其注入__construct方法中。
在基础结构层中,我已执行此合同。我写了一些看起来像IoC容器的东西,它通过自动布线注入创建服务。
一切正常。但是我知道服务的依赖关系将会增长。我将向他们添加更多 UseCases 。还有另一个问题-容器会注入所有依赖项,但是我们只能使用一个 UseCase ,所以它将做很多工作。
好吧,如果我要注入IoC容器本身而不是许多参数,并在 UseCases 中使用它。
IoC合同也位于域层合同名称空间中
答案 0 :(得分:0)
好吧,如果我要注入IoC容器本身而不是很多参数
不,这不好。为Composition Root之外的任何类提供对无限制的依赖集的访问权被视为一种反模式。此反模式称为Service Locator。
注入容器会使类对冗余组件(容器)产生依赖关系,并使该类的依赖关系变得不明显。这使测试变得复杂,并使类在其复杂性级别上不诚实。
您可能会尝试注入容器以防止类的构造函数不断变化,但这是另一个问题的迹象。不断获取新依赖关系的类可能会违反Single Responsibility Principle。您将最终得到带有许多构造函数参数的类-一种称为Constructor over-injection的代码味。