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

我在kzu的博客上留言问了同样的问题。遗憾的是,他在编码之前没有阐明这样一个特性的用例。

我能想到的唯一一件事是,如果你想在应用程序的不同部分从容器中解析不同的类型。例如,如果订单输入系统有两个单独的部分,并且每个部分都是相同的,只是它们需要显示不同的产品列表,则可以为每个部分创建子容器,并“覆盖”每个部分中产品存储库的注册。每当一个部分试图解析产品存储库(或任何依赖于产品存储库的内容)时,它都会得到您在子容器而不是父容器中设置的实例。有点像重写虚拟方法。

这可能有点离谱,但这是我能想到的最好的了。

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

如果项目完全接受依赖注入,那么就有充分的理由使用子容器。让我们设想一个应用程序处理来自两个不同但相似的系统的消息。大多数处理是类似的,但也有一些变化来支持这些系统的兼容性。我们的目标是重用我们可以重用的代码,同时根据需求的不同编写不同的代码。

在OO编程中,我们将一系列类连接在一起,这些类将协作以满足系统需求。DI容器承担这个责任。当消息从系统到达时,我们希望构建一组适合于处理来自该特定系统的消息的协作类。

我们有一个顶级容器,其中的物品在两个系统之间没有变化。然后,我们有子容器 做 不同的系统会有所不同。当消息到达时,我们向适当的子DI容器请求 messageProcessor . 根据容器的配置(必要时返回父容器),DI框架可以为所讨论的系统返回messageProcessor(由适当的协作者支持的对象)。

如果这不是一个明确的答案,请留下评论。此外,您还可以搜索“机器人腿问题”。每条腿都是一样的,但一条腿需要左脚,另一条腿需要右脚。我们可以为每条腿配备一个儿童DI容器。