为什么要使用第三方DI容器而不是内置的ASP.NETCore DI容器？

Question

目前，缺乏关于DI主题依赖注入的文档。与现有解决方案（Ninject、Autofac、StructureMap）相比，使用内置DI有哪些优点/缺点？默认依赖注入的当前限制是什么（如果有的话）？

Answer 1

此外，有人能帮助我了解这些注册之间的区别吗？

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IService, Service>();
    services.AddScoped<IService, Service>();
    services.AddSingleton<IService, Service>();
    services.AddInstance(service);
}

https://stackoverflow.com/revisions/30681477/8

• 瞬态-每次检索时都实例化
• Scoped-每个超文本传输协议请求实例化一次，并将在超文本传输协议请求的生命周期内可用
• Singleton-实例化一次，并将在您的应用程序的整个生命周期内可用
• 实例-等效于单例，除了您提供对象实例而不是创建实例的框架

资料来源：http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles, http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency-injection-in-6-steps/

为了进一步解释为什么它被称为作用域，请考虑以下代码：

// app startup
var services = new ServiceCollection();
services.AddScoped<IService, Service>();
var startupServices = services.BuildServiceProvider();
// request init
var requestServices = statupServices.CreateScope().ServiceProvider;

因此，在 ASP.NET HttpContext.RequestServices 的创建方式与上面类似，其中 CreateScope 在请求开始时被调用。但它可以在 ASP.NET 之外的上下文中使用，在这种情况下，范围可能具有与每个请求不同的含义。

Answer 2

这里解释一下：

• 瞬态-每次创建一个新实例
• 作用域-在当前作用域内创建单个实例。它相当于当前范围内的单例。
• Singleton—创建一个实例，其行为与Singleton类似。
• 实例-始终给定一个特定实例。您负责其初始创建

Alpha版本有此限制：

• 它仅支持构造函数注入
• 它只能解析具有一个且只有一个公共构造函数的类型
• 它不支持高级功能（如按线程范围或自动发现）

如果你没有编写非常复杂的产品默认DI容器，对你来说应该足够了。在其他情况下，您可以尝试已经提到的具有高级功能的库。

我的建议是从默认的开始，当（如果）你遇到一些你不能用它做的事情时，改变实现。

Answer 3

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

• 它无法帮助您验证配置，因此很难诊断由常见配置错误引起的问题。在规模合理的应用程序中，实际上很难自己发现这些错误。更新：MS 的版本 3。DI 现在包含一个名为 ValidateOnBuild 的功能，但它唯一要做的就是检查是否可以满足所有注册的所有依赖项。
• 使用拦截器或装饰器以可维护的方式应用横切关注点是不可能的。这使得维护任何合理大小的应用程序更加昂贵。更新：有几个第三方库试图填补空白，但由于MS中的限制。DI，它们不能完全填补这一空白（例如，装饰开放通用注册，确保处理装饰实例等）。
• 虽然女士。DI 支持将开放泛型抽象映射到开放泛型实现，其实现相当幼稚，并且无法使用具有类型约束、更复杂的泛型类型映射和方差的泛型类型。
• 在使用Auto-Wireing时，不可能进行条件/上下文注册，例如，当有两个组件Service1和Service2都依赖于ILogger时，您可能希望将Service1与NullLogger注入，使用FileLogger注入Service2，或者您希望使用Logger注入Service1。

存在这些限制的主要原因是因为内置容器的目标是为框架本身提供DI功能，同时保持其功能集最小化，希望更成熟的DI容器能够与之集成。换句话说，它试图充当最小公分母(LCD)。由于它的LCD功能，它永远也不能成长为一个成熟的DI容器，对应用程序开发来说是实用的(如果不违背作为LCD的promise的话)。

如果你从一个新的简单的项目开始，我的建议是应用纯DI。这意味着您可以在不使用容器和不创建自己的DI容器的情况下手工连接复合根中的组件。相反，您可以通过插入自定义IControllerActivator来解析您的类型。稍后，当自动连接、自动注册和拦截等特性可以提高组合根的可维护性时，切换到一个满足您需求的已建立的DI库。