dependency-injection - 如何使用依赖注入(inject)而不是服务定位器

Question

我听到有人说你不应该为你的依赖注入(inject)使用服务定位器。那么如何在不依赖服务定位器的情况下注入(inject)依赖项呢？我想尝试 IoC 容器，但不想陷入反模式。

您是否应该设置所有内容，以便所有类始终具有到最深层类的依赖链？ (如果我/那完全有意义的话)

让您的所有代码都依赖于所选 IoC 容器是不对的，对吗？

那么你在哪里“使用”你的容器(用于 rexolving)？你如何让它解决所有问题，就像你的代码一样深入？它是通过在每一层直到前层使用接口(interface)以正确的方式设计一切的一部分吗？

还是我漏掉了一点？

让我提醒您，我只是不想陷入反模式，需要一些提示/提醒。

Answer 1

Should you just set everything up so there is one place where all classes always have a dependency chain to the deepest classes? (if I/that makes sense at all)

是的，这称为应用程序的组合根，您可以在其中配置 IoC 容器并解析根类型。

It isn't right to have all your code littered with dependencies on the IoC container of choice, is it?

正确，最好不要围绕您的类型传递对 IoC 容器的引用，因为这会降低它们的可重用性，并且通常会将类型与 IoC 容器的概念相结合。

So where do you "use" your the container (for rexolving)? And how do you get it to resolve everything, as deep as your code goes? Is it a part of designing everything the right way by using interfaces through every layer up till the front layer?

您可以在组合根目录以及代码中需要通过容器实例化类型(即从工厂类型)的任何地方使用容器(通常用于依赖链支持)。

许多 IoC 容器可以为您生成这些工厂类型，因此您只需要通过，例如IMyFactory作为依赖项，或者在某些 IoC 容器的情况下，一个 Func<IMyService> .这意味着您不需要创建依赖于 IoC 容器的工厂类型。

在使用接口(interface)方面，依赖倒置原则规定你应该依赖抽象，而不是具体化，所以如果你想采用依赖注入(inject)，你需要考虑到这个概念来分解你的代码。