dependency-injection - 这种 ioc 行为背后的原因是什么（使用多个注册组件解决）

Question

当给定像（C＃windsor）这样的场景时，这似乎是ioc的标准方法：

container.AddComponent<ILogger, HttpLogger>();
container.AddComponent<ILogger, SmtpLogger>();

var logger = container.Resolve<ILogger>();

可能是在解析组件时，第一个注册的 ILogger（在本例中为 HttpLogger）是解析的唯一候选者，然后 ioc 将在它认为可以解决所有依赖项的地方找到它可以找到的“最胖”构造函数。

但是，很可能是 ioc 无法解决第一个记录器的依赖关系，因此会返回解决问题，如果 ioc 尝试过，很可能 SmtpLogger 可能已经解决。

那么只使用第一个注册的服务作为候选人的原因是什么？似乎您将获得哪种类型的不确定性是一个参数，但随后 ioc 将负责它使用的构造函数。

那么为什么不从所有适用类型的所有构造函数中挑选，并开始尝试从最胖的构造函数向下解析（与真实类型无关）？

这可能有一个非常明显的答案，但老实说我不知道。

在此先感谢斯蒂芬。

score 2 · Accepted Answer

原因是它对实现复杂性的影响。

当这种行为被实现时，它会递归地工作，例如，确定是否可以满足其中一个记录器的依赖关系将需要遍历它的所有依赖关系等等。

要有效地做到这一点很困难，并且给容器和调试体验增加了很多复杂性。

MEF 虽然不是严格意义上的 IoC 容器，但确实以类似于您建议的方式执行此操作 - 它是稳定组合行为的一部分，我们称之为“拒绝”。

在高度动态的插件场景中，拒绝非常有用。在 Windsor、Autofac 等所针对的场景中，额外的努力并没有得到太多回报。

1 回答 1