我一直关注Daniel Cazzulino's关于building a DI container using TDD的系列文章。在part five of the series中，他添加了对容器层次结构的支持，而没有评论使该功能有用的原因。我已经看到在许多DI框架中提到对层次结构的支持，但是我很难理解它们何时被使用，以及为什么。有人可以提供一些见解吗？
答案 0 :(得分：1)
我对kzu的博客发表评论，提出同样的问题。遗憾的是，他在编写代码之前没有澄清这种功能的用例。
我唯一能想到的是，如果您希望在应用的不同部分从容器中解析出不同的类型。例如，如果您有一个包含两个单独部分的订单输入系统，并且每个部分都相同，只是他们需要提供不同的产品列表，您可以为每个部分创建一个子容器，并“覆盖”您的注册每个产品库。每当某个部分试图解析产品存储库（或任何依赖于它的东西）时，它将获得您在子容器而不是父容器中设置的实例。有点像重写虚拟方法。
这可能远离基础，但这是我能想到的最好的。
答案 1 :(得分：1)
Here's a sample在类似于Matt描述的场景中使用子容器。它使用子容器在不同的数据库配置之间进行选择。
这里的关键是大多数配置在子容器之间共享（共享部分属于父容器）
答案 2 :(得分：0)
如果项目完全接受依赖注入，那么拥有子容器是有充分理由的。让我们假设一个应用程序处理来自两个不同但类似系统的消息。大多数处理都是类似的，但是有一些变化可以支持这些系统的兼容性。我们的目标是重用我们可以使用的代码，同时根据需求编写不同的代码。
在面向对象编程中，我们将一系列课程连接在一起，这些课程将协作以满足系统要求。 DI容器承担这一责任。当消息从系统到达时，我们希望构建一组适合处理来自该特定系统的消息的协作类。
我们有一个顶级容器，其中的项目在两个系统之间没有变化。然后，我们在系统之间有做的子容器。当消息到达时，我们向approriate child DI容器询问messageProcessor。根据该容器的配置（根据需要回退到父容器），DI框架可以为相关系统返回messageProcessor（由合作伙伴支持的对象）。
如果这不是一个明确的答案，请发表评论。此外，您可以搜索“机器人腿问题”。每条腿都相同，但一只需要左脚，另一只需要右脚。我们每条腿都可以有一个儿童DI容器。
答案 3 :(得分：0)
我了解嵌套容器的最佳示例是窗口系统。只关注问题，让每个标签/窗口拥有独立于其他标签/窗口的自己的容器，所有窗口容器都从父容器继承全局依赖关系，这非常好。
如果您可以有重复的选项卡/窗口，则尤其需要这样做，因为在许多情况下，您希望为每个重复的选项卡/窗口分别设置不同类的实例