【发布时间】:2018-10-16 10:23:48
【问题描述】:
我的理解是,当使用内置的依赖注入时,.NET Core 控制台应用程序将要求您自己创建和管理所有范围,而 ASP.NET Core 应用程序将默认创建和管理HttpRequest 范围通过定义的中间件。
使用 ASP.NET Core,您可以选择创建和管理自己的范围,当您需要位于 HttpRequest 之外的服务时,您可以调用 CreateScope()。
很明显,每次调用IServiceScopeFactory.CreateScope()都会创建一个新的IServiceScope;但是,是否每次调用IServiceProvider.CreateScope()扩展方法也会创建一个新的IServiceScope?
基本上,在 ASP.NET Core 和 .NET Core 控制台应用程序中创建范围的以下方法之间是否存在有意义的区别:
public class Foo()
{
public Foo(IServiceProvider serviceProvider)
{
using(var scope = serviceProvider.CreateScope())
{
scope.ServiceProvider.GetServices<>();
}
}
}
和
public class Bar()
{
public Bar(IServiceScopeFactory scopeFactory)
{
using(var scope = scopeFactory.CreateScope())
{
scope.ServiceProvider.GetServices<>();
}
}
}
【问题讨论】:
-
IServiceProvider.CreateScope将解析IServiceScopeFactory并在其上调用CreateScope。所以在功能上这两种方法是相同的,因为一个调用另一个。 -
少一行代码是的。 fwiw:除了少数罕见的基础设施案例外,您不必将范围工厂或服务提供者都注入到您的类中
-
这是有道理的——避免使用服务定位器模式。在我的例子中,注入是针对
IHostedService/BackgroundService的,它需要它自己的范围与 ASP.NET 默认值分开。这将只是服务的一次注入,所有依赖项都将从StartUp.cs中的注册中解决。我正在努力注入ApplicationDbContext(范围进入单例=异常)。通过注册一个单例 contextFactory 解决了这个问题。对这种方法有什么想法吗?对吗? -
CreateScope 还用于任何根应用程序容器,例如 webhost 服务提供者。根应用程序提供者和它创建的所有对象将在应用程序的生命周期中存在。如果我们从根容器实例解析范围或临时服务它们将被创建为单例。相反,通过使用范围,我们可以确保尊重它们的预期生命周期。示例 var host = CreateWebHostBuilder(args).Build();使用 (var scope = host.Services.CreateScope()) { var services = scope.ServiceProvider; var ds = services.GetService
(); -
@CK - 我有一个类似的场景 - 需要异步后台服务。因此,我将我的服务注册为 HostedService,然后使用注入的 IServiceProvider 到 GetRequiredService
()。关于某个主题的好文章:docs.microsoft.com/en-us/dotnet/architecture/microservices/…
标签: c# asp.net-core dependency-injection .net-core