IOC“子”容器/服务定位器答案

【问题标题】：The IOC "child" container / Service LocatorIOC“子”容器/服务定位器
【发布时间】：2011-02-07 15:02:13
【问题描述】：

免责声明：我知道 DI 和服务定位器模式之间存在争议。我有一个旨在避免辩论的问题。这个问题是针对服务定位器爱好者的，他们碰巧像 Fowler 一样思考“DI……很难理解……总的来说，除非我需要，否则我宁愿避免它。”就我的问题而言，我必须避免 DI（故意未给出原因），因此我不试图引发与我的问题无关的辩论。

问题：将 IOC 容器保持在单例中（请记住我上面的免责声明）我可能会看到的唯一问题是使用子容器。大概子容器本身不会是单例的。起初我认为这是一个真正的问题。但想了想，我开始觉得这正是我想要的行为（子容器不是单例，可以随意Disposed()）。

然后我的思想进一步进入了哲学领域。因为我是服务定位器的粉丝，所以我想知道子容器的概念首先有多么必要。在我看到有用性的一小部分情况下，要么是满足 DI（无论如何我都在避免），要么问题是可以在不求助于 IOC 容器的情况下解决的。我的想法部分受到了IServiceLocator interface 的启发，它甚至懒得列出“GetChildContainer”方法。

所以我的问题是：如果您是服务定位器的粉丝，您是否发现子容器通常没有实际意义？否则，它们什么时候是必不可少的？

额外的功劳：如果单例中的服务定位器存在其他哲学问题（除了 DI 倡导者提出的问题），它们是什么？

【问题讨论】：

标签： singleton ioc-container service-locator

【解决方案1】：

恕我直言：

子容器与服务定位器无关，即它们是正交的。使用容器作为服务定位器只是一种使用方式，与容器是否支持子容器无关。
子容器的使用很大程度上取决于容器设计。例如，虽然 Windsor 支持它们，但它们很少被使用。 Autofac OTOH 大量使用它们来管理范围/组件生命周期。它是任何容器/服务定位器实现的完全可选功能，这就是 IServiceLocator 没有提及它的原因。 IServiceLocator 的工作是提供服务定位器中的最小公分母。

【讨论】：

您的答案正是我想要的，甚至更好！您花时间指出子容器在各种框架中的使用频率（一个非常有用的花絮）！！！也许我可以再麻烦您一次：Unity 在“子容器频率”范围内的位置是什么？ Unity 中的子容器使用更像 Windsor（不经常）还是更像 Autofac（经常）？
抱歉，我对 Unity 没有丰富的经验。