ASP.NET Core 3框架揭秘之 异步线程无法使用IServiceProvider问题

标题反映的是上周五一个同事咨询我的问题,我觉得这是一个很好的问题。这个问题有助于我们深入理解依赖注入框架在ASP.NET Core中的应用,以及服务实例的生命周期。

一、问题重现

我们通过一个简单的实例来模拟该同事遇到的问题。我们采用极简的方式创建了如下这个ASP.NET Core MVC应用。如下面的代码片段所示,除了注册与ASP.NET Core MVC框架相关的服务与中间件之外,我们还调用了IHostBuilder的UseDefaultServiceProvider方法将配置选项ServiceProviderOptions的ValidateScopes属性设置为True,以开启针对服务范围的验证。我们还采用Scoped生命周期模式注册了服务IFoobar,具体的实现类型Foobar还实现了IDisposable接口。

public class Program
{
 public static void Main()
 {
 Host
 .CreateDefaultBuilder()
 .UseDefaultServiceProvider(options => options.ValidateScopes = true)
 .ConfigureWebHostDefaults(builder => builder
 .ConfigureLogging(logging => logging.ClearProviders())
 .ConfigureServices(services => services
  .AddScoped<IFoobar, Foobar>()
  .AddRouting()
  .AddControllers())
 .Configure(app => app
  .UseRouting()
  .UseEndpoints(endpoints => endpoints.MapControllers())))
 .Build()
 .Run();
 }
}

public interface IFoobar { }
public class Foobar : IFoobar, IDisposable
{
 public void Dispose() => Console.WriteLine("Foobar.Dispose();");
}

我们创建了如下这个HomeController,它的构造函数中注入了一个IServiceProvider对象。在Action方法Index中,我们调用Task的静态方法Run异步执行了一些操作。具体来说,在异步执行的操作中,我们利用调用上面注入的这个IServiceProvider对象的GetRequiredService<T>方法试图获取一个IFoobar服务实例。由于这段操作时在一个Try/Catch中执行的,抛出的异常消息的堆栈信息会直接输出到控制台上。

public class HomeController: Controller
{
 private readonly IServiceProvider _requestServices;
 public HomeController(IServiceProvider requestServices)
 {
 _requestServices = requestServices;
 }
 [HttpGet("/")]
 public IActionResult Index()
 {
 Task.Run(async() => {
 try
 {
 await Task.Delay(100);
 var foobar = _requestServices.GetRequiredService<IFoobar>();
 }
 catch (Exception ex)
 {
 Console.WriteLine(ex.Message);
 Console.WriteLine(ex.StackTrace);
 }
 });
 return Ok();
 }
}

在运行该应用程序后,我们利用浏览器采用根路径(“/”)对Action方法Index发起访问后,服务端控制台上会出现如下所示的错误信息。

二、ApplicationServices与RequestServices

从上图所示的错误消息可以看出,问题出在我们试图利用一个被Dispose的IServiceProvider来获取我们所需的服务实例。我们知道,ASP.NET Core应用在启动和请求处理过程中所需的服务几乎都是由代表DI容器的IServiceProvider提供的。具体来说,这里存在着两种类型的IServiceProvider对象,一种与当前应用的生命周期保持一致,我们一般将其称为ApplicationServices,另一种则是具体针对每个请求的IServiceProvider对象,我们将其称为RequestServices。

一般来说,ApplicationServices用于提供管道构建过程中所需的服务实例,具体请求处理过程中所需的服务实例一般由RequestServices提供。具体来说,对于接收的每一个请求,ASP.NET Core框架都会利用ApplicationServices创建一个代表服务范围的IServiceScope对象,后者就是对RequestServices的封装。在完成了针对请求的处理之后,服务范围被终结,RequestServices被Dispose。

对于我们演示的实例来说,注入到HomeController构造函数中的IServiceProvider是RequestServices,由于针对RequestServices的使用是在另一个后台线程中执行的,并且在使用的时候针对当前请求的处理已经结束(因为我们人为等待了100毫秒),自然就会出现上图所示的异常。

三、如何获取ApplicationServices

既然与请求绑定的RequestServices不能用,我们只能使用与应用绑定的ApplicationServices,那么后者如何得到呢?ASP.NET Core 3采用了基于IHost/IHostBuilder的承载方式,表示宿主的IHost接口具有如下所示的Services属性,它返回的正式我们所需的ApplicationServices。

public interface IHost : IDisposable
{
 Task StartAsync(CancellationToken cancellationToken = new CancellationToken());
 Task StopAsync(CancellationToken cancellationToken = new CancellationToken());

 IServiceProvider Services { get; }
}

对于我们演示的程序来说,我们可以采用如下的方式在HomeController的构造中注入IHost服务的方式间接地获得这个ApplicationServices对象。

public class HomeController: Controller
{
 private readonly IServiceProvider _applicationServices;
 public HomeController(IHost host)
 {
 _applicationServices = host.Services;
 }
 [HttpGet("/")]
 public IActionResult Index()
 {
 Task.Run(async() => {
 try
 {
 await Task.Delay(100);
 var foobar = _applicationServices.GetRequiredService<IFoobar>();
 }
 catch (Exception ex)
 {
 Console.WriteLine(ex.Message);
 Console.WriteLine(ex.StackTrace);
 }
 });
 return Ok();
 }
}

当我们采用如上的方式将RequestServices替换成ApplicationServices之后,我们的问题是否就解决了呢?在采用上面相同的方式进行测试之后,我们会发现服务端控制台上出现了如下所示的错误消息。

四、服务实例的生命周期

上面的问题是由我们试图利用一个代表“根容器”的IServiceProvider对象去解析一个生命周期模式为Scoped服务实例导致,具体的原因在《依赖注入[8]:服务实例的生命周期》已经讲得很清楚了。为了解决这个问题,我们应该根据ApplicationServices创建一个“服务范围”,并在该服务范围内提取我们所需的服务实例。为了确保服务实例能够被正常回收,我们还应该将代表服务范围的IServiceScope对象及时终结掉。如下所示的是正确的编程方式。

public class HomeController: Controller
{
 private readonly IServiceProvider _applicationServices;
 public HomeController(IHost host)
 {
 _applicationServices = host.Services;
 }
 [HttpGet("/")]
 public IActionResult Index()
 {
 Task.Run(async() => {
 await Task.Delay(100);
 using (var scope = _applicationServices.CreateScope())
 {
 var foobar = scope.ServiceProvider.GetRequiredService<IFoobar>();
 }
 });
 return Ok();
 }
}

五、统一的解决方案

之前我们将问题的解决方案落实在如何获取与当前应用具有相同生命周期的ApplicationServices上,所以我们采用注入IHost的方式得到这个ApplicationServices。如果采用传统的基于IWebHost/IWebHostBuilder的承载方式,IHost自然是获取不到了。但是我们是真的需要这个ApplicationServices对象吗?其实不是,我们真正需要的是利用它创建一个代表服务范围的IServiceScope对象,并在该范围内消费我们所需的服务实例。由于IServiceScope是通过IServiceScopeFactory创建的,所以我们只需要注入IServiceScopeFactory即可。

public class HomeController : Controller
{
 private readonly IServiceScopeFactory _serviceScopeFactory;

 public HomeController(IServiceScopeFactory serviceScopeFactory)
 {
 _serviceScopeFactory = serviceScopeFactory;
 }

 [HttpGet("/")]
 public IActionResult Index()
 {
 Task.Run(async () =>
 {
 await Task.Delay(100);
 using (var scope = _serviceScopeFactory.CreateScope())
 {
 var foobar = scope.ServiceProvider.GetRequiredService<IFoobar>();
 }
 });
 return Ok();
 }
}

总结

以上所述是小编给大家介绍的ASP.NET Core 3框架揭秘之 异步线程无法使用IServiceProvider问题,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对我们网站的支持!
如果你觉得本文对你有帮助,欢迎转载,烦请注明出处,谢谢!

(0)

相关推荐

  • asp.net core webapi项目配置全局路由的方法示例

    一.前言 在开发项目的过程中,我新创建了一个controller,发现vs会给我们直接在controller头添加前缀,比如[Route("api/[controller]")],即在访问接口的时候会变成http://localhost:8000/api/values,但是如果控制器有很多个,或者要进行版本迭代时,我们会发现痛苦的时刻降临了,要一个一个的修改. 如果在这个时候可以进行全局配置前缀那真是福利呀,修改一处即可.为了能达到此目的我们就来运用一下吧. 二.配置 0.在配置前我们

  • ASP.NET Core使用自定义验证属性控制访问权限详解

    前言 大家都知道在应用中,有时我们需要对访问的客户端进行有效性验证,只有提供有效凭证(AccessToken)的终端应用能访问我们的受控站点(如WebAPI站点),此时我们可以通过验证属性的方法来解决. 本文将详细介绍ASP.NET Core使用自定义验证属性控制访问权限的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧 方法如下 一.public class Startup的配置: //启用跨域访问(不同端口也是跨域) services.AddCors(options

  • 详解ASP.NET Core WebApi 返回统一格式参数

    业务场景: 业务需求要求,需要对 WebApi 接口服务统一返回参数,也就是把实际的结果用一定的格式包裹起来,比如下面格式: { "response":{ "code":200, "msg":"Remote service error", "result":"" } } 具体实现: using Microsoft.AspNetCore.Mvc; using Microsoft.AspNe

  • ASP.NET Core DI手动获取注入对象的方法

    依赖注入简单介绍: 依赖注入(Dependency injection , DI)是一种实现对象及其合作者或依赖项之间松散耦合的技术.将类用来执行其操作的这些对象以某种方式提供给该类,而不是直接实例化合作者或使用静态引用. ASP.NET Core DI 一般使用构造函数注入获取对象,比如在ConfigureServices配置注入后,通过下面方式获取: private IValueService _valueService; public ValueController(IValueServi

  • ASP.NET Core 3框架揭秘之 异步线程无法使用IServiceProvider问题

    标题反映的是上周五一个同事咨询我的问题,我觉得这是一个很好的问题.这个问题有助于我们深入理解依赖注入框架在ASP.NET Core中的应用,以及服务实例的生命周期. 一.问题重现 我们通过一个简单的实例来模拟该同事遇到的问题.我们采用极简的方式创建了如下这个ASP.NET Core MVC应用.如下面的代码片段所示,除了注册与ASP.NET Core MVC框架相关的服务与中间件之外,我们还调用了IHostBuilder的UseDefaultServiceProvider方法将配置选项Servi

  • ASP.NET Core 6框架揭秘实例演示之如何承载你的后台服务

    目录 [S1401]利用承载服务收集性能指标 [S1402]依赖注入的应用 [S1403]配置选项的应用 [S1404]提供针对环境的配置 [S1405]日志的应用 [S1406]在配置中定义日志过滤规则 借助 .NET提供的服务承载(Hosting)系统,我们可以将一个或者多个长时间运行的后台服务寄宿或者承载我们创建的应用中.任何需要在后台长时间运行的操作都可以定义成标准化的服务并利用该系统来承载,ASP.NET Core应用最终也体现为这样一个承载服务. 借助 .NET提供的服务承载(Hos

  • Asp.net core前端框架Blazor介绍

    一.Blazor介绍 Blazor是微软在Asp.net core 3.0中推出的一个前端MVVM模型,它可以利用Razor页面引擎和C#作为脚本语言来构建WEB页面. 在.Net5中,Blazor将代替传统的Web Pages.可以代替如下代码简单演示了它的基本功能: 和Angular JS和VUE的模型非常类似,Blazor 支持大多数应用所需的核心方案: 参数 事件处理 数据绑定 路由 依赖关系注入 布局 模板 级联值 使用Blazor主要有如下好处: C# 语言:使用 C# 代替 Jav

  • 详解Spring框架下向异步线程传递HttpServletRequest参数的坑

    在spring的注解 @RequestMapping 之下可以直接获取 HttpServletRequest 来获得诸如request header等重要的请求信息: @Slf4j @RestController @RequestMapping("/test") public class TestController { private static final String HEADER = "app-version"; @RequestMapping(value

  • 详解IIS在ASP.NET Core下的两种部署模式

    目录 一.ASP.NET CORE Core Module 二. In-Process部署模式 三.Out-of-Process部署模式 四.<aspnetcore>配置 KestrelServer最大的优势体现在它的跨平台的能力,如果ASP.NET CORE应用只需要部署在Windows环境下,IIS也是不错的选择.ASP.NET CORE应用针对IIS具有两种部署模式,它们都依赖于一个IIS针对ASP.NET CORE Core的扩展模块.本文提供的示例演示已经同步到<ASP.NET

  • 关于dotnet 替换 ASP.NET Core 的底层通讯为命名管道的 IPC 库的问题

    目录 背景 使用方法 服务端 客户端 这是一个用于本机多进程进行 IPC 通讯的库,此库的顶层 API 是采用 ASP.NET Core 的 MVC 框架,其底层通讯不是传统的走网络的方式,而是通过 dotnetCampus.Ipc 开源项目提供的基于 NamedPipeStream 命名管道的方式进行通讯.相当于替换掉 ASP.NET Core 的底层通讯方式,从走网络换成命名管道的方式.本库的优势是可以使用设计非常好的 ASP.NET Core 的 MVC 框架作为顶层调用 API 层,底层

  • 在Asp.Net Core中使用ModelConvention实现全局过滤器隔离

    从何说起 这来自于我把项目迁移到Asp.Net Core的过程中碰到一个问题.在一个web程序中同时包含了MVC和WebAPI,现在需要给WebAPI部分单独添加一个接口验证过滤器 IActionFilter ,常规做法一般是写好过滤器后给需要的控制器挂上这个标签,高级点的做法是注册一个全局过滤器,这样可以避免每次手动添加同时代码也更好管理.注册全局过滤器的方式为: services.AddMvc(options => { options.Filters.Add(typeof(AccessCon

  • 如何在Asp.Net Core MVC中处理null值的实现

    译文链接:https://www.infoworld.com/article/3434624/how-to-handle-null-values-in-aspnet-core-mvc.html 传统的 asp.net mvc 对应着 .netcore 中的 asp.net core mvc,可以利用 asp.net core mvc 去构建跨平台,可扩展,高性能的web应用和 api 接口. 程序员都有一些洁癖,很多时候我们都想很完美的包装一些错误信息,如一些返回空response的reques

  • ASP.NET Core中实现全局异常拦截的完整步骤

    前言 异常是一种运行时错误,当异常没有得到适当的处理,很可能会导致你的程序意外终止,这篇就来讨论一下如何在 ASP.Net Core MVC 中实现全局异常处理,我会用一些 样例代码 和 截图 来说明这些概念. 全局异常处理 其实在 ASP.Net Core MVC 框架中已经有了全局异常处理的机制,你可以在一个中心化的地方使用 全局异常处理中间件 来进行异常拦截,如果不用这种中心化方式的话,你就只能在 Controller 或者 Action 作用域上单独处理,这会导致异常处理代码零散在项目各

  • 详解ASP.NET Core 中的框架级依赖注入

    1.ASP.NET Core 中的依赖注入 此示例展示了框架级依赖注入如何在 ASP.NET Core 中工作. 其简单但功能强大,足以完成大部分的依赖注入工作.框架级依赖注入支持以下 scope: Singleton - 总是返回相同的实例 Transient - 每次都返回新的实例 Scoped - 在当前(request)范围内返回相同的实例 假设我们有两个要通过依赖注入来进行工作的工件: PageContext - 自定义请求上下文 Settings - 全局应用程序设置 这两个都是非常

随机推荐