最近，我一直在尝试理解使用Service Locator"反模式"和使用Castle Windsor容器之间的区别。我在网上找到了一些信息，并在一篇未完成的博客文章中总结了我到目前为止学到的东西。
编辑:直到现在，我一直认为依赖注入是所有需要保证分离。但无论我往哪里看，都能看到有人在推动温莎城堡(Castle Windsor)等集装箱的发展。我想清楚地了解原因。请……把我当一个6岁的孩子来解释
你居然像六岁小孩一样要求解释;像你五岁时那样解释:
我看到的每一个地方都在向Castle Windsor等容器的方向发展
坦率地说，我认为这样做的原因是大多数人实际上不理解依赖注入是什么，这意味着他们没有掌握控制反转的概念，而是去寻找他们已经习惯的new关键字的替代品。然后他们找到一个DI容器，并(错误地)将其用作服务定位器。不幸的是，这很容易做到。
这就是为什么在我的书中，我解释了所有的DI概念，而没有将解释与任何一个DI容器耦合。这实际上是本书的大部分。
服务定位器和依赖注入是实现松耦合的两种根本不同的尝试。服务定位器有许多缺点，并且没有DI所没有的优点。这就是为什么我认为将Service Locator称为反模式是安全的。
你不需要DI容器来使用DI;事实上，我想说的是，除非你采用一种相当复杂的方法，否则最好避免使用。
服务定位器可能只是一个特定的控制反转容器(如Castle Windsor)的包装器。关键是你的代码应该(理想地)引用容器的唯一位置是在你的组合根。
因为控制反转容器支持依赖链，当你从容器解析根类型时，它的所有依赖项都会被注入，以及任何后代依赖项。
如果您希望在运行时创建进一步的类型，那么您可以使用工厂，如果您希望利用容器提供的依赖链和实现接口的容器映射，那么工厂也可以有对容器的引用。
当您使用服务定位器时，您的代码将为各处的服务调用定位器。当使用控制反转时，只有一个地方(组合根)可以调用容器。你的应用程序的其余部分不应该是容器感知的