asp.net - 为什么要使用第三方 DI 容器而不是内置 ASP.NET Core DI 容器？

Question

目前缺乏有关 DI 主题的文档 - Dependency Injection 。与现有解决方案(Ninject、Autofac、StructureMap)相比，使用内置 DI 有何优点/缺点？默认依赖注入(inject)的当前限制是什么(如果有)？

Answer 1

对于任何实行松散耦合并遵循 SOLID 原则的合理规模应用程序的产品开发，.NET Core 的 DI 容器 (MS.DI) 不适合，因为:

• 它无法帮助您验证配置，因此很难诊断常见错误配置带来的问题。在一个相当大小的应用程序中，您自己实际上很难发现这些错误。 更新:MS.DI 版本 3 现在包含一个名为 ValidateOnBuild 的功能，但它唯一做的就是检查所有注册的所有依赖关系是否都能得到满足。
• 无法申请Cross-Cutting Concerns使用拦截器或 decorators以可维护的方式。这使得维护任何合理大小的应用程序都更加昂贵。 更新:有几个第三方库试图填补这一空白，但由于 MS.DI 的限制，它们无法完全填补该空白(例如，装饰开放通用注册、确保装饰实例的处置等)
• 虽然 MS.DI 支持开放通用抽象到开放通用实现的映射，但其实现相当 naive并且无法使用具有类型约束、更复杂的泛型类型映射和方差的泛型类型。
• 是 impossible进行条件/上下文注册，在使用自动接线时，注册仅被注入(inject)到特定的一组消费者。例如当有两个组件时 Service1和Service2两者都依赖于 ILogger ，您可能想注入(inject) Service1与 NullLogger和Service2与 FileLogger ，或者你想要Service1注入(inject)Logger<Service1>和Service2与 Logger<Service2> .

存在这些限制的主要原因是内置容器的目标是为框架本身提供 DI 功能，同时将其功能集保持在最低限度，以期更成熟的 DI 容器能够能够与之融为一体。换句话说，它尝试充当最小公分母 (LCD)。由于其 LCD 功能，它永远无法成长为可用于应用程序开发的成熟的 DI 容器(并非不违背作为 LCD 的 promise )。

如果您从一个新的简单项目开始，我的建议是申请 Pure DI 。这意味着您可以在 Composition Root 内手动连接组件。 不使用容器并且不创建您自己的 DI 容器。相反，您可以通过插入 your custom IControllerActivator 来解析您的类型。 。稍后，当自动接线、自动注册和拦截等功能可以提高您的组合根的可维护性时，请切换到符合您要求的已建立的 DI 库之一。