我听说人们说你不应该使用服务定位器来进行依赖注入。那么如何在不依赖服务定位器的情况下注入依赖项呢？我想尝试 IoC 容器，但不想陷入反模式。
您是否应该将所有内容都设置好，以便所有类始终具有到最深类的依赖链？ （如果我/那有道理的话）
让你的所有代码都依赖于所选的 IoC 容器是不对的，是吗？
那么您在哪里“使用”您的容器（用于重新求解）？以及如何让它解决所有问题，就像你的代码一样深入？它是通过使用贯穿每一层直到最前层的接口以正确方式设计一切的一部分吗？
或者我只是错过了一点？
让我提醒你，我只是不想陷入反模式，需要一些提示/提醒。
【问题讨论】：
标签： dependency-injection inversion-of-control service-locator
你应该把所有东西都设置好 有一个地方所有课程 总是有一个依赖链到 最深的课程？ （如果我/那使 完全有道理）
是的，这称为应用程序的组合根，您可以在其中配置 IoC 容器并解析根类型。
拥有所有代码是不对的 到处都是对 IoC 的依赖 选择的容器，是吗？
正确，最好不要在类型周围传递对 IoC 容器的引用，因为这会降低它们的可重用性，并且通常会将类型与 IoC 容器的概念结合起来。
那么你在哪里“使用”你的 容器（用于重新解决）？以及怎么做 你得到它来解决一切，因为 你的代码有多深？是不是一部分 以正确的方式设计一切 通过使用每个接口 一层一层到最前面？
您可以在组合根目录以及代码中需要通过容器实例化类型（即从工厂类型）的任何地方（通常用于依赖链支持）使用容器。
很多 IoC 容器可以为你生成这些工厂类型，所以你只需要传递，例如IMyFactory 作为依赖项，或者在某些 IoC 容器的情况下，Func<IMyService>。这意味着您不需要创建依赖于您的 IoC 容器的工厂类型。
在使用接口方面，依赖倒置原则指出，您应该依赖抽象，而不是具体化，因此如果您希望采用依赖注入，则需要在考虑到这一概念的代码中进行分解。
【讨论】：