从EFCore上下文的使用到深入剖析DI的生命周期最后实现自动属性注入

2023-08-03 14:22:06 80

故事背景

最近在把自己的一个老项目从Framework迁移到.NetCore3.0，数据访问这块选择的是EFCore+Mysql。使用EF的话不可避免要和DbContext打交道，在Core中的常规用法一般是：创建一个XXXContext类继承自DbContext，实现一个拥有DbContextOptions参数的构造器，在启动类StartUp中的ConfigureServices方法里调用IServiceCollection的扩展方法AddDbContext，把上下文注入到DI容器中，然后在使用的地方通过构造函数的参数获取实例。OK，没任何毛病，官方示例也都是这么来用的。但是，通过构造函数这种方式来获取上下文实例其实很不方便，比如在Attribute或者静态类中，又或者是系统启动时初始化一些数据，更多的是如下一种场景：

publicclassBaseController:Controller
{
publicBloggingContext_dbContext;
publicBaseController(BloggingContextdbContext)
{
_dbContext=dbContext;
}

publicboolBlogExist(intid)
{
return_dbContext.Blogs.Any(x=>x.BlogId==id);
}
}

publicclassBlogsController:BaseController
{
publicBlogsController(BloggingContextdbContext):base(dbContext){}
}

从上面的代码可以看到，任何要继承BaseController的类都要写一个“多余”的构造函数，如果参数再多几个，这将是无法忍受的（就算只有一个参数我也忍受不了）。那么怎样才能更优雅的获取数据库上下文实例呢，我想到以下几种办法。

DbContext从哪来

1、直接开溜new

回归原始，既然要创建实例，没有比直接new一个更好的办法了，在Framework中没有DI的时候也差不多都这么干。但在EFCore中不同的是，DbContext不再提供无参构造函数，取而代之的是必须传入一个DbContextOptions类型的参数，这个参数通常是做一些上下文选项配置例如使用什么类型数据库连接字符串是多少。

publicBloggingContext(DbContextOptionsoptions):base(options)
{
}

默认情况下，我们已经在StartUp中注册上下文的时候做了配置，DI容器会自动帮我们把options传进来。如果要手动new一个上下文，那岂不是每次都要自己传？不行，这太痛苦了。那有没有办法不传这个参数？肯定也是有的。我们可以去掉有参构造函数，然后重写DbContext中的OnConfiguring方法，在这个方法中做数据库配置：

protectedoverridevoidOnConfiguring(DbContextOptionsBuilderoptionsBuilder)
{
optionsBuilder.UseSqlite("Filename=./efcoredemo.db");
}

即使是这样，依然有不够优雅的地方，那就是连接字符串被硬编码在代码中，不能做到从配置文件读取。反正我忍受不了，只能再寻找其他方案。

2、从DI容器手动获取

既然前面已经在启动类中注册了上下文，那么从DI容器中获取实例肯定是没问题的。于是我写了这样一句测试代码用来验证猜想：

varcontext=app.ApplicationServices.GetService();

不过很遗憾抛出了异常：

报错信息说的很明确，不能从rootprovider中获取这个服务。我从G站下载了DI框架的源码（地址是https://github.com/aspnet/Extensions/tree/master/src/DependencyInjection），拿报错信息进行反向追溯，发现异常来自于CallSiteValidator类的ValidateResolution方法：

publicvoidValidateResolution(TypeserviceType,IServiceScopescope,IServiceScoperootScope)
{
if(ReferenceEquals(scope,rootScope)
&&_scopedServices.TryGetValue(serviceType,outvarscopedService))
{
if(serviceType==scopedService)
{
thrownewInvalidOperationException(
Resources.FormatDirectScopedResolvedFromRootException(serviceType,
nameof(ServiceLifetime.Scoped).ToLowerInvariant()));
}

thrownewInvalidOperationException(
Resources.FormatScopedResolvedFromRootException(
serviceType,
scopedService,
nameof(ServiceLifetime.Scoped).ToLowerInvariant()));
}
}

继续往上，看到了GetService方法的实现：

internalobjectGetService(TypeserviceType,ServiceProviderEngineScopeserviceProviderEngineScope)
{
if(_disposed)
{
ThrowHelper.ThrowObjectDisposedException();
}

varrealizedService=RealizedServices.GetOrAdd(serviceType,_createServiceAccessor);
_callback?.OnResolve(serviceType,serviceProviderEngineScope);
DependencyInjectionEventSource.Log.ServiceResolved(serviceType);
returnrealizedService.Invoke(serviceProviderEngineScope);
}

可以看到，_callback在为空的情况下是不会做验证的，于是猜想有参数能对它进行配置。把追溯对象换成_callback继续往上翻，在DI框架的核心类ServiceProvider中找到如下方法：

internalServiceProvider(IEnumerableserviceDescriptors,ServiceProviderOptionsoptions)
{
IServiceProviderEngineCallbackcallback=null;
if(options.ValidateScopes)
{
callback=this;
_callSiteValidator=newCallSiteValidator();
}
//省略....
}

说明我的猜想没错，验证是受ValidateScopes控制的。这样来看，把ValidateScopes设置成False就可以解决了，这也是网上普遍的解决方案：

.UseDefaultServiceProvider(options=>
{
options.ValidateScopes=false;
})

但这样做是极其危险的。

为什么危险？到底什么是rootprovider？那就要从原生DI的生命周期说起。我们知道，DI容器被封装成一个IServiceProvider对象，服务都是从这里来获取。不过这并不是一个单一对象，它是具有层级结构的，最顶层的即前面提到的rootprovider，可以理解为仅属于系统层面的DI控制中心。在Asp.NetCore中，内置的DI有3种服务模式，分别是Singleton、Transient、Scoped，Singleton服务实例是保存在rootprovider中的，所以它才能做到全局单例。相对应的Scoped，是保存在某一个provider中的，它能保证在这个provider中是单例的，而Transient服务则是随时需要随时创建，用完就丢弃。由此可知，除非是在rootprovider中获取一个单例服务，否则必须要指定一个服务范围（Scope），这个验证是通过ServiceProviderOptions的ValidateScopes来控制的。默认情况下，Asp.NetCore框架在创建HostBuilder的时候会判定当前是否开发环境，在开发环境下会开启这个验证：

所以前面那种关闭验证的方式是错误的。这是因为，rootprovider只有一个，如果恰好有某个singleton服务引用了一个scope服务，这会导致这个scope服务也变成singleton，仔细看一下注册DbContext的扩展方法，它实际上提供的是scope服务：

如果发生这种情况，数据库连接会一直得不到释放，至于有什么后果大家应该都明白。

所以前面的测试代码应该这样写：

using(varserviceScope=app.ApplicationServices.CreateScope())
{
varcontext=serviceScope.ServiceProvider.GetService();
}

与之相关的还有一个ValidateOnBuild属性，也就是说在构建IServiceProvider的时候就会做验证，从源码中也能体现出来：

if(options.ValidateOnBuild)
{
Listexceptions=null;
foreach(varserviceDescriptorinserviceDescriptors)
{
try
{
_engine.ValidateService(serviceDescriptor);
}
catch(Exceptione)
{
exceptions=exceptions??newList();
exceptions.Add(e);
}
}

if(exceptions!=null)
{
thrownewAggregateException("Someservicesarenotabletobeconstructed",exceptions.ToArray());
}
}

正因为如此，Asp.NetCore在设计的时候为每个请求创建独立的Scope，这个Scope的provider被封装在HttpContext.RequestServices中。

[小插曲]

通过代码提示可以看到，IServiceProvider提供了2种获取service的方式：

这2个有什么区别呢？分别查看各自的方法摘要可以看到，通过GetService获取一个没有注册的服务时会返回null，而GetRequiredService会抛出一个InvalidOperationException，仅此而已。

//返回结果:
//AserviceobjectoftypeTornullifthereisnosuchservice.
publicstaticTGetService(thisIServiceProviderprovider);

//返回结果:
//AserviceobjectoftypeT.
//
//异常:
//T:System.InvalidOperationException:
//ThereisnoserviceoftypeT.
publicstaticTGetRequiredService(thisIServiceProviderprovider);

终极大招

到现在为止，尽管找到了一种看起来合理的方案，但还是不够优雅，使用过其他第三方DI框架的朋友应该知道，属性注入的快感无可比拟。那原生DI有没有实现这个功能呢，我满心欢喜上G站搜Issue，看到这样一个回复（https://github.com/aspnet/Extensions/issues/2406）：

官方明确表示没有开发属性注入的计划，没办法，只能靠自己了。

我的思路大概是：创建一个自定义标签（Attribute），用来给需要注入的属性打标签，然后写一个服务激活类，用来解析给定实例需要注入的属性并赋值，在某个类型被创建实例的时候也就是构造函数中调用这个激活方法实现属性注入。这里有个核心点要注意的是，从DI容器获取实例的时候一定要保证是和当前请求是同一个Scope，也就是说，必须要从当前的HttpContext中拿到这个IServiceProvider。

先创建一个自定义标签：

[AttributeUsage(AttributeTargets.Property)]
publicclassAutowiredAttribute:Attribute
{

}

解析属性的方法：

publicvoidPropertyActivate(objectservice,IServiceProviderprovider)
{
varserviceType=service.GetType();
varproperties=serviceType.GetProperties().AsEnumerable().Where(x=>x.Name.StartsWith("_"));
foreach(PropertyInfopropertyinproperties)
{
varautowiredAttr=property.GetCustomAttribute();
if(autowiredAttr!=null)
{
//从DI容器获取实例
varinnerService=provider.GetService(property.PropertyType);
if(innerService!=null)
{
//递归解决服务嵌套问题
PropertyActivate(innerService,provider);
//属性赋值
property.SetValue(service,innerService);
}
}
}
}

然后在控制器中激活属性：

[Autowired]
publicIAccountService_accountService{get;set;}

publicLoginController(IHttpContextAccessorhttpContextAccessor)
{
varpro=newAutowiredServiceProvider();
pro.PropertyActivate(this,httpContextAccessor.HttpContext.RequestServices);
}

这样子下来，虽然功能实现了，但是里面存着几个问题。第一个是由于控制器的构造函数中不能直接使用ControllerBase的HttpContext属性，所以必须要通过注入IHttpContextAccessor对象来获取，貌似问题又回到原点。第二个是每个构造函数中都要写这么一堆代码，不能忍。于是想有没有办法在控制器被激活的时候做一些操作？没考虑引入AOP框架，感觉为了这一个功能引入AOP有点重。经过网上搜索，发现Asp.NetCore框架激活控制器是通过IControllerActivator接口实现的，它的默认实现是DefaultControllerActivator（https://github.com/aspnet/AspNetCore/blob/master/src/Mvc/Mvc.Core/src/Controllers/DefaultControllerActivator.cs）：

///
publicobjectCreate(ControllerContextcontrollerContext)
{
if(controllerContext==null)
{
thrownewArgumentNullException(nameof(controllerContext));
}

if(controllerContext.ActionDescriptor==null)
{
thrownewArgumentException(Resources.FormatPropertyOfTypeCannotBeNull(
nameof(ControllerContext.ActionDescriptor),
nameof(ControllerContext)));
}

varcontrollerTypeInfo=controllerContext.ActionDescriptor.ControllerTypeInfo;

if(controllerTypeInfo==null)
{
thrownewArgumentException(Resources.FormatPropertyOfTypeCannotBeNull(
nameof(controllerContext.ActionDescriptor.ControllerTypeInfo),
nameof(ControllerContext.ActionDescriptor)));
}

varserviceProvider=controllerContext.HttpContext.RequestServices;
return_typeActivatorCache.CreateInstance

从EFCore上下文的使用到深入剖析DI的生命周期最后实现自动属性注入

热门推荐

随机推荐