为什么依赖注入框架支持容器层次结构？

Question

我一直在关注Daniel Cazzulino's系列约building a DI container using TDD。在part five of the series中，他添加了对容器层次结构的支持，但没有对该功能的用途进行评论。我已经在很多DI框架中看到提及对层次结构的支持，但是我很难理解何时使用它们以及为什么。有人可以提供一些见解吗？

Answer 1

Here's a sample在类似于Matt描述的场景中使用子容器。它使用子容器来选择不同的数据库配置。

这里的关键是，大部分的配置是子容器之间共享（即共享部分父容器所属）

Answer 2

我在kzu的博客上留言评论同一个问题。在编码之前，他没有澄清这个特性的用例是件令人遗憾的事情。

我唯一能想到的就是如果你想在应用程序的不同部分从你的容器中解析出不同的类型。例如，如果您有一个包含两个单独部分的订单输入系统，并且每个部分都相同，但他们需要提供不同的产品清单，则可以为每个部分创建一个子容器，然后“覆盖”您的注册每个产品存储库。无论何时某个部分试图解析产品存储库（或任何依赖于其的产品存储库），它都将获得您在子容器中设置的实例，而不是父级。有点像重写虚拟方法。

这可能是远离基地，但它是我能想到的最好的。

Answer 3

有很好的理由为有孩子的容器，如果依赖注入完全由项目拥抱。让我们设想一个应用程序处理来自两个不同但类似系统的消息。大多数处理过程是相似的，但是支持这些系统兼容性的方式有所不同。我们的目标是重新使用我们可以的代码，同时根据需求的不同编写不同的代码。

在OO编程中，我们连接了一系列可协作满足系统要求的类。 DI容器承担这一责任。当消息从系统到达时，我们想要构建一组适合处理来自特定系统的消息的协作类。

我们有一个顶级容器，其中的项目在两个系统之间没有变化。然后，我们有子容器做不同系统之间。当一条消息到达时，我们会询问合适的子女DI容器messageProcessor。基于该容器的配置（根据需要回退到父容器），DI框架可以返回正在讨论的系统的messageProcessor（由适当的协作者支持的对象）。

如果这不是一个明确的答案，请发表评论。此外，您可以搜索“机器人腿问题”。每条腿是相同的，但一个需要左脚，另一个需要右脚。每条腿都可以有一个儿童DI容器。

Answer 4

我知道的嵌套容器的最佳示例是窗口系统。将关注点分离是非常好的事情，让每个选项卡/窗口具有独立于其他选项卡/窗口的容器，并且所有窗口容器都从父容器继承全局依赖项。

如果您可以拥有重复的选项卡/窗口，这尤其需要，因为在很多情况下，您希望为每个重复选项卡/窗口显示不同类别的实例