? 优质资源分享 ?
学习路线指引(点击解锁) | 知识定位 | 人群定位 |
---|---|---|
? Python实战微信订餐小程序 ? | 进阶级 | 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。 |
?Python量化交易实战? | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
大家好,我是张飞洪,感谢您的阅读,我会不定期和你分享学习心得,希望我的文章能成为你成长路上的垫脚石,让我们一起精进。
在本章中,我们将学习ASP.NET Core
的依赖项注入(DI)以及如何自定义它。
我们将讨论以下主题:
- 使用不同的DI容器
- 探索ConfigureServices方法
- 使用其他的ServiceProvider
- Scrutor简介
技术准备
我们使用以下命令(你可以在console, shell,
或Bash
终端),创建一个MVC
应用:
dotnet new mvc -n DiSample -o DiSample
在Visual Studio中打开项目,或在控制台中键入以下命令,在Visual Studio Code
中打开项目:
cd DiSample
code .
使用不同的DI容器
在大多数项目中,我们其实不需要使用不同的DI容器。ASP.NET Core
中的现有DI基本上满足我们的需要。但是,你可能喜欢其他DI容器的其他功能:
- 使用
Ninject
创建一个支持模块作为轻量级依赖项的应用程序。比如,您可能希望将模块放入特定目录中,并在应用程序中自动注册这些模块。 - 在应用程序外部的配置文件中,比如,在XML或JSON文件中,而不是仅在C#中配置服务。这是各种DI容器中的常见功能,但
ASP.NET Core
中尚不支持。 - 在运行时添加服务,获取动态的DI容器,这也是一些DI容器中的常见特性。
现在,让我们看看ConfigureServices
方法是如何操作的。
探索ConfigureServices
方法
我们将当前的ConfigureServices
方法与以前的长期支持版本(TLS)进行比较,看看有什么变化。如果您使用版本3.1创建的ASP.NET Core
项目,并打开Startup.cs
文件,配置服务的方法如下所示:
public void ConfigureServices(IServiceCollection services)
{
services.Configure(options =>
{
options.CheckConsentNeeded = context => true;
});
services.AddControllersWithViews();
services.AddRazorPages();
}
相反,在 ASP.NET Core 6.0
,没有启动Startup.cs
,服务的配置在Startup.cs
中进行,如下所示:
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddControllersWithViews();
var app = builder.Build();
// The rest of the file isn't relevant for this chapter
这两种情况都可以获得IServiceCollection
,其中默认已经填充了ASP.NET Core
所需的一组服务,比如宿主服务、ConfigureServices
方法之前执行的相关服务。
以上方法中,添加了更多的服务。
- 首先,将包含
cookie
策略选项的配置类添加到ServiceCollection
。 AddMvc()
方法添加MVC框架所需的服务。
到目前为止,我们有大约140个服务注册到IServiceCollection
。
但是,服务集合不是实际的DI容器,真实的DI容器被包装在所谓的服务提供者中(ServiceProvider
)。
那么应该如何获取DI容器呢?
IServiceCollection
有了一个扩展方法,它用于从服务集合中创建IServiceProvider
,代码如下:
IServiceProvider provider = services.BuildServiceProvider()
ServiceProvider
包含不可变容器,即在运行时无法更改。在ConfigureServices
方法执行后,会在后台创建IServiceProvider
。
接下来,我们再看下如何在DI定制过程中,替代IServiceProvider
。
使用其他IServiceProvider
如果其他容器已经支持ASP.NET Core
,则更改为其他或自定义DI容器将变得非常容易。通常,第三方DI容器会使用IServiceCollection
做为自己的容器,它通过循环集合将已注册的服务移动到另一个容器。
我们用第三方容器Autofac
举个例子。在命令行中键入以下命令,加载NuGet
包:
dotnet add package Autofac.Extensions.DependencyInjection
要注册自定义IoC
容器,通常需要注册不同的IServiceProviderFactory
,IServiceProviderFactory
将创建一个ServiceProvider
实例。如果第三方容器支持ASP.NET Core
,则必须提供一个该工厂类。如果你要使用Autofac
,则需要使用AutofacServiceProviderFactory
。
我们在Program.cs
中给IHostBuilder
编写一个扩展方法,内部注册一个AutofacServiceProviderFactory
:
using Autofac;
using Autofac.Extensions.DependencyInjection;
namespace DiSample;
public static class IHostBuilderExtension {
public static IHostBuilder UseAutofacServiceProviderFactory(this IHostBuilder hostbuilder)
{
hostbuilder.UseServiceProviderFactory (new AutofacServiceProviderFactory());
return hostbuilder;
}
}
注意,不要忘记将引入名称空间:Autofac
和Autofac.Extensions.DependencyInjection
。
要使用此扩展方法,可以在Program.cs
中使用AutofacServiceProvider
:
var builder = WebApplication.CreateBuilder(args);
builder.Host.UseAutofacServiceProviderFactory();
// Add services to the container.
builder.Services.AddControllersWithViews();
以上通过扩展方法将AutofacServiceProviderFactory
添加到IHostBuilder
中,并启用Autofac
IoC容器。后续会转而使用Autofac
向IServiceCollection
添加服务。
再强调一下,除非必要。通常,我们不一定要替换现有的.NET Core
DI容器。
Scrutor简介
在本章的开头,我提到了服务的自动注册,这里可以通过其他DI容器完成。这里介绍一个名为Scrutor
的不错的NuGet包来实现。Scrutor
通过向.NET Core
DI容器向IServiceCollection
添加一个扩展方法,用以自动注册服务。
扩展阅读
这里介绍一篇关于Scrutor
的非常详细的博客文章,建议您继续阅读这篇文章以了解更多信息。
回顾
通过以上演示,我们将能够使用任何.NET标准兼容的DI容器替换现有容器。如果您选择的容器不包括ServiceProvider
,请自己实现一个IServiceProvider
接口,并在其中使用DI容器。如果您选择的容器没有提供填充服务的方法,请自行创建自己的方法。循环已注册的服务并将其添加到另一个容器中。
最后一步听起来很简单,实现起来比较费劲,因为需要将所有的IServiceCollection
注册转换为其他容器的注册,它的复杂性取决于其他DI容器的实现细节。
任何时候,我们都可以选择使用任何与.NET标准兼容的DI容器,替换ASP.NET Core
中的许多默认实现。
在下一章我们将探讨如何以不同的方式配置HTTPS
,感谢您的阅读。
+## (^_^)打个赏喝个咖啡(^_^)
转载请注明:xuhss » 定制.NET 6.0的依赖注入