在我们平常开发中会有这样的需求,我们的Service业务层需要获取请求上下文中的用户信息,一般我们从控制器参数传递过来。如果你觉得这样就可以了,请您关闭文章。

但是我们也会遇到控制器传递困难的场景,我自己最近使用单库实现多租户的PAAS平台,发现EF Core上下文获取我Token或者Headers中获取租户Id进行全局过滤就很麻烦(多租户解决方案后期我补充)。

我们先要知道一个思想如果想要整个.NET程序中共享一个变量,我们可以将想要共享的变量放在某个类的静态属性上来实现。
但是我们的请求上下文每个人的信息不一样,就需要将这个变量的共享范围缩小到单个线程内。例如在web应用中,服务器为每个同时访问的请求分配一个独立的线程,我们要在这些独立的线程中维护自己的当前访问用户的信息时,就需要需要线程本地存储了。

  • IHttpContextAccessor 设置实现规范
  • HttpContextAccessor 基于当前执行上下文提供的实现。
  • AsyncLocal 实现多线程中静态变量独立化 (这里画一个圈圈)

这个时候我们再看源码思路就清晰了,我们通过注入HttpContextAccessor,然后内部将请求上下文保存在_httpContextCurrent静态变量中,这个就可以全局访问啦(当然访问范围是在该主线程内部)。

  1. // HttpContextAccessor源码
  2.     public class HttpContextAccessor : IHttpContextAccessor
  3.     {
  4. // 通过AsyncLocal保存当前上下文信息
  5.         private static readonly AsyncLocal<HttpContextHolder> _httpContextCurrent =new AsyncLocal<HttpContextHolder>();
  6.         public HttpContext? HttpContext
  7.         {
  8.             get
  9.             {
  10.                 return  _httpContextCurrent.Value?.Context;
  11.             }
  12.             set
  13.             {
  14.                 var holder = _httpContextCurrent.Value;
  15.                 if (holder != null)
  16.                 {
  17.                     // 清除AsyncLocals中捕获的当前HttpContext
  18.                     holder.Context = null;
  19.                 }
  20.                 if (value != null)
  21.                 {
  22.                     // 使用一个对象间接在AsyncLocal中保存HttpContext,
  23.                     // 所以当它被清除时,它可以在所有的ExecutionContexts中被清除。
  24.                     _httpContextCurrent.Value = new HttpContextHolder { Context =
  25. value };
  26.                 }
  27.             }
  28.         }
  29.         private class HttpContextHolder
  30.         {
  31.             public HttpContext? Context;
  32.         }

首先我们需要在Startup的ConfigureServices方法中注册IHttpContextAccessor的实例

  1. public void ConfigureServices(IServiceCollection services)
  2. {
  3. services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
  4. ....
  5. }

这个时候你Service层注入该类的时候就可以获取到请求上下文信息了,但是这个就不符合我们诗一般程序员的气质。
因为直接将请求上下文本抛出来还挺多的,我们本来只需要租户ID但是你给我一坨,挺不好把握的。

我们可以进行包装,我使用PrincipalAccessor进行请求上下文拆解

然后在Startup的ConfigureServices方法中,我们一样把这个类也加入注册中

  1. public void ConfigureServices(IServiceCollection services)
  2. {
  3. services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
  4. services.AddSingleton<IPrincipalAccessor, PrincipalAccessor>();
  5. ....
  6. }

自己不断的在优化自己的项目结构,或者设计思路,我发现我为什么有这么多注入,我构造函数都要爆了。

然后自己想了想,我其实可以将访问上下文的类放入BaseService中静态变量存储,系统提供了IServiceCollection来注册服务和提供了IServiceProvider这个让我们解析各种注册过的服务.
我们定义一个存储类

  1. public class ServiceProviderInstance
  2. {
  3. public static IServiceProvider Instance { get; set; }
  4. } 
  1. public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
  2. {
  3. ...
  4. ServiceProviderInstance.Instance = app.ApplicationServices;
  5. }

宝贝相信我剩下的我们交给时间,我们只需要这样(BaseService定义属性、获取注入就可以了),然后就那样(就直接可以使用啦)

  1. public class BaseService<T, Repository> : IBaseService<T>
  2. where T : BaseEntityCore, new()
  3. //规定这个Repository类型一定是继承仓储的接口,下面就可以使用接口的方法
  4. where Repository : IBaseRepository<T>
  5. {
  6. /// <summary>
  7. /// 身份信息
  8. /// </summary>
  9. protected IClaimsAccessor Claims { get; set; }
  10. /// <summary>
  11. /// 获取仓储实体
  12. /// </summary>
  13. private readonly Repository CurrentRepository;
  14. public BaseService(Repository currentRepository)
  15. {
  16. CurrentRepository = currentRepository;
  17. Claims = ServiceProviderInstance.Instance.GetRequiredService<IClaimsAccessor>();
  18. }
  19. .....
  20. }

版权声明:本文为chenxi001原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/chenxi001/p/14998845.html