定制.NET 6.0的依赖注入 .net依赖注入原理

大家好，我叫张飞鸿。感谢您的阅读。希望我的文章能够成为你成长的垫脚石。

本章是《定制ASP NET 6.0框架系列文章》的第三部分。在本章中，您将了解ASP.NET Core 中的依赖注入(DI) 以及如何自定义它。

我们将讨论以下主题：

使用不同的DI 容器探索ConfigureServices 方法使用其他ServiceProviderScrutors

技术准备

使用以下命令（可以在控制台、shell 或Bash 终端中运行）：创建MVC 应用程序。

dotnet new mvc -n DiSample -o DiSample

在Visual Studio 中打开项目，或在控制台中键入以下命令以在Visual Studio Code 中打开项目。

cdDi样本

代码。

使用不同的DI容器

大多数项目实际上并不需要使用不同的DI 容器。 ASP.NET Core中现有的DI基本上满足了我们的需求。但是，您可能更喜欢其他DI 容器的其他功能。

使用Ninject 创建支持模块作为轻量级依赖项的应用程序。例如，您可能希望将模块放置在特定目录中并自动将它们注册到您的应用程序中。使用C# 以及应用程序外部的配置文件（例如XML 或JSON 文件）配置您的服务。这是各种DI 容器中的常见功能，但ASP.NET Core 尚不支持。在运行时添加服务来获取动态DI容器也是一些DI容器的常见功能。

接下来，我们来看看ConfigureServices方法是如何工作的。

探索ConfigureServices方法

让我们将当前的ConfigureServices 方法与之前的长期支持版本(TLS) 进行比较，看看发生了什么变化。如果您有一个在3.1 版本中创建的ASP.NET Core 项目并打开Startup.cs 文件，则配置该服务的方法如下：

公共无效ConfigureServices（IServiceCollection服务）

{

services.ConfigureCookiePolicyOptions（选项=

{

options.CheckConsentNeeded=context=true;

});

services.AddControllersWithViews();

services.AddRazorPages();

}

相比之下，在ASP.NET Core 6.0 中，Startup.cs 没有启动，服务配置在Startup.cs 中完成，如下所示：

varbuilder=WebApplication.CreateBuilder(args);

//将服务添加到容器中。

builder.Services.AddControllersWithViews();

varapp=builder.Build();

//文件的其余部分与本章无关

无论哪种情况，您都可以获得IServiceCollection。它默认已经拥有了ASP.NET Core 所需的一组服务，包括主机服务以及在ConfigureServices方法之前运行的相关服务。

上面的方法增加了更多的服务。

首先，将包含cookie 策略选项的配置类添加到ServiceCollection。 AddMvc() 方法将所需的服务添加到MVC 框架。

到目前为止，IServiceCollection 中已注册了大约140 个服务。

然而，服务集合并不是真正的DI 容器，而是被封装成所谓的服务提供者（ServiceProvider）。

那么如何获得DI 容器呢？

IServiceCollection 具有用于从服务集合创建IServiceProvider 的扩展方法。这是代码：

IServiceProvider 提供者=services.BuildServiceProvider()

ServiceProvider 包含一个不可变的容器。也就是说，它不能在运行时更改。当ConfigureServices方法运行时，会在后台创建一个IServiceProvider。

现在我们来看看如何在DI定制过程中替换IServiceProvider。

使用其他IServiceProvider

如果其他容器已经支持ASP.NET Core，则更改为另一个DI 容器或自定义DI 容器非常容易。第三方DI 容器通常使用IServiceCollection 作为自己的容器，并回收该集合以将注册的服务移动到另一个容器。

我们以第三方容器Autofac为例。通过在命令行中键入以下命令来加载NuGet 包：

添加dotnet 包Autofac.Extensions.DependencyInjection

注册自定义IoC 容器通常需要注册一个单独的IServiceProviderFactory 来创建ServiceProvider 实例。如果您的第三方容器支持ASP.NET Core，则必须提供工厂类。如果使用Autofac，则必须使用AutofacServiceProviderFactory。

在Program.cs中编写IHostBuilder的扩展方法，并在内部注册AutofacServiceProviderFactory。

使用Autofac。

使用Autofac.Extensions.DependencyInjection。

命名空间DiSample；

公共静态类IHostBuilderExtension {

公共静态IHostBuilderUseAutofacServiceProviderFactory（此IHostBuilder 主机生成器）

{

Hostbuilder.UseServiceProviderFactory (new AutofacServiceProviderFactory());

返回主机构建器。

}

}

请注意，我们记得引入命名空间Autofac 和Autofac.Extensions.DependencyInjection。

要使用此扩展方法，请在Program.cs 中使用AutofacServiceProvider。

var builder=WebApplication.CreateBuilder(args);

builder.Host.UseAutofacServiceProviderFactory();

//将服务添加到容器中。

builder.Services.AddControllersWithViews();

上面通过扩展方法将AutofacServiceProviderFactory添加到IHostBuilder中，并启用AutofacIoC容器。稍后，使用Autofac 将服务添加到IServiceCollection。

再次强调，除非必要。一般来说，您不一定需要替换现有的.NET CoreDI 容器。

Scrutor简介

在本章开头，我们讨论了可以通过其他DI 容器运行的服务的自动注册。这是一个适合称为Scrutor 的实现的NuGet 包。 Scrutor 将IServiceCollection 的扩展方法添加到.NET Core DI 容器中，以自动注册服务。

参考

可以在此处找到有关Scrutor 的非常详细的博客文章。欲了解更多信息，我们建议您继续阅读这篇文章。

回顾

上述演示允许您将现有容器替换为符合.NET 标准的DI 容器。如果您选择的容器不包含ServiceProvider，请自行实现IServiceProvider 接口并在其中使用DI 容器。如果您选择的容器不提供配置服务的方法，请创建您自己的容器。循环遍历注册的服务并将它们添加到另一个容器中。

最后一步看似简单，但其复杂性取决于其他DI 容器的实现细节，因为它需要将所有IServiceCollection 注册转换为其他容器中的注册。

您可以随时选择替换ASP.NET Core 的许多默认实现并使用符合.NET 标准的DI 容器。

下一章将介绍如何以各种方式配置HTTPS。感谢您的阅读。

以上#.NET 6.0中自定义依赖注入的相关内容来源网络，仅供参考。相关信息请参见官方公告。