迷幻高中,7 k7k,黑川优花
ABP在其内部实现了工作单元模式,统一地进行事务与连接管理。 其核心就是通过 Castle 的 Dynamic Proxy 进行动态代理,在组件注册的时候进行拦截器注入,拦截到实现了 Unit Of Work 特性的方法进行操作,在执行完方法之后就会关闭掉工作单元。
其整体流程大概如下:
一旦在方法 procced 执行的时候,产生任何异常触发任何异常都不会执行 Complete 方法,直接抛出终止执行。
这是一个 Castle Interceptors 的实现,在 AbpBootStrap 的 Initialze 方法当中被注入到 Ioc 容器。
private void AddInterceptorRegistrars() { ValidationInterceptorRegistrar.Initialize(IocManager); AuditingInterceptorRegistrar.Initialize(IocManager); EntityHistoryInterceptorRegistrar.Initialize(IocManager); UnitOfWorkRegistrar.Initialize(IocManager); AuthorizationInterceptorRegistrar.Initialize(IocManager); }
之后在 Registrar 内部针对组件注入事件进行绑定:
public static void Initialize(IIocManager iocManager) { iocManager.IocContainer.Kernel.ComponentRegistered += (key, handler) => { var implementationType = handler.ComponentModel.Implementation.GetTypeInfo(); HandleTypesWithUnitOfWorkAttribute(implementationType, handler); HandleConventionalUnitOfWorkTypes(iocManager, implementationType, handler); }; }
在这里的两个方法分别是针对已经实现了 UnitOfWork 特性的类进行绑定,另外一个则是针对符合命名规则的类型进行拦截器绑定。
拦截器做的事情十分简单,针对拦截到的方法进行 UOW 特性检测,如果检测通过之后则直接执行工作单元方法,并根据特性生成 Options。不过不是一个 UOW 的话,则直接继续执行原先方法内代码。
var unitOfWorkAttr = _unitOfWorkOptions.GetUnitOfWorkAttributeOrNull(method); if (unitOfWorkAttr == null || unitOfWorkAttr.IsDisabled) { //No need to a uow invocation.Proceed(); return; } PerformUow(invocation, unitOfWorkAttr.CreateOptions());
在创建 UOW 的时候,拦截器也会根据方法类型的不同来用不同的方式构建 UOW 。
如果是同步方法的话:
private void PerformSyncUow(IInvocation invocation, UnitOfWorkOptions options) { // 直接从 Manager 生成一个新的工作单元 using (var uow = _unitOfWorkManager.Begin(options)) { // 继续执行原方法 // 产生异常直接进入 uow 的 Dispose 方法 invocation.Proceed(); // 如果一切正常,提交事务 uow.Complete(); } }
但如果这个工作单元被标注在异步方法上面,则操作略微复杂:
private void PerformAsyncUow(IInvocation invocation, UnitOfWorkOptions options) { // 获得一个工作单元 var uow = _unitOfWorkManager.Begin(options); // 继续执行拦截到的方法 try { invocation.Proceed(); } catch { uow.Dispose(); throw; } // 如果是异步无返回值的方法 if (invocation.Method.ReturnType == typeof(Task)) { invocation.ReturnValue = InternalAsyncHelper.AwaitTaskWithPostActionAndFinally( (Task) invocation.ReturnValue, async () => await uow.CompleteAsync(), exception => uow.Dispose() ); } else //Task<TResult> { invocation.ReturnValue = InternalAsyncHelper.CallAwaitTaskWithPostActionAndFinallyAndGetResult( invocation.Method.ReturnType.GenericTypeArguments[0], invocation.ReturnValue, async () => await uow.CompleteAsync(), exception => uow.Dispose() ); } }
以上代码在进入的时候直接执行原方法,如果产生任何异常直接进入 Dispose 方法并且抛出异常。乍一看与同步方法处理没什么区别,但重点是这里并没有执行 Complete 方法,因为这里需要对其异步返回结果更改为 UOW 异步提交之后的值,先查看第一种直接返回 Task 的情况.
public static async Task AwaitTaskWithPostActionAndFinally(Task actualReturnValue, Func<Task> postAction, Action<Exception> finalAction) { Exception exception = null; try { // 原有异步任务返回值 await actualReturnValue; // 新的异步返回结果 await postAction(); } catch (Exception ex) { exception = ex; throw; } finally { finalAction(exception); } }
在内部首先等待原有任务执行完成之后再执行传入的 UOW 的 CompleteAsync() 方法,并且在执行过程中有无异常都会直接调用 UOW 的 Disopse 释放资源。
第二种则适用于有返回值的情况:
public static object CallAwaitTaskWithPostActionAndFinallyAndGetResult(Type taskReturnType, object actualReturnValue, Func<Task> action, Action<Exception> finalAction) { // 获得 AwaitTaskWithPreActionAndPostActionAndFinallyAndGetResult 方法,并且通过反射构造一个泛型方法,并且将自身参数传入调用。 return typeof (InternalAsyncHelper) .GetMethod("AwaitTaskWithPostActionAndFinallyAndGetResult", BindingFlags.Public | BindingFlags.Static) .MakeGenericMethod(taskReturnType) .Invoke(null, new object[] { actualReturnValue, action, finalAction }); } public static async Task<T> AwaitTaskWithPreActionAndPostActionAndFinallyAndGetResult<T>(Func<Task<T>> actualReturnValue, Func<Task> preAction = null, Func<Task> postAction = null, Action<Exception> finalAction = null) { Exception exception = null; try { if (preAction != null) { await preAction(); } var result = await actualReturnValue(); if (postAction != null) { await postAction(); } return result; } catch (Exception ex) { exception = ex; throw; } finally { if (finalAction != null) { finalAction(exception); } } }
这两个方法的作用都是确保 CompleteAsync 和 Dispose 能够在放在异步任务当中执行。
顾名思义,这是一个 UOW 的管理器,在 ABP 内部有其一个默认实现 UnitOfWorkManager
,在 AbpKernel 模块初始化的时候就已经被注入。
核心方法是 Begin 方法,在 Begin 方法当中通过 FillDefaultsForNonProvidedOptions
方法判断是否传入了配置参数,如果没有传入的话则构建一个默认参数对象。
public IUnitOfWorkCompleteHandle Begin(UnitOfWorkOptions options) { // 如果没有 UOW 参数,构造默认参数 options.FillDefaultsForNonProvidedOptions(_defaultOptions); var outerUow = _currentUnitOfWorkProvider.Current; // 当前是否已经存在工作单元,存在工作单元的话,构建一个内部工作单元 if (options.Scope == TransactionScopeOption.Required && outerUow != null) { return new InnerUnitOfWorkCompleteHandle(); } // 不存在的话构建一个新的工作单元 var uow = _iocResolver.Resolve<IUnitOfWork>(); // 绑定各种事件 uow.Completed += (sender, args) => { _currentUnitOfWorkProvider.Current = null; }; uow.Failed += (sender, args) => { _currentUnitOfWorkProvider.Current = null; }; uow.Disposed += (sender, args) => { _iocResolver.Release(uow); }; //Inherit filters from outer UOW if (outerUow != null) { options.FillOuterUowFiltersForNonProvidedOptions(outerUow.Filters.ToList()); } uow.Begin(options); //Inherit tenant from outer UOW if (outerUow != null) { uow.SetTenantId(outerUow.GetTenantId(), false); } // 设置当前工作单元为新创建的 UOW _currentUnitOfWorkProvider.Current = uow; return uow; }
这里 Begin 方法所返回的是一个 IUnitOfWorkCompleteHandle
对象,跳转到 IUnitOfWorkCompleteHandle
,可以看到它有两个方法:
public interface IUnitOfWorkCompleteHandle : IDisposable { void Complete(); Task CompleteAsync(); }
都是完成工作单元的方法,一个同步、一个异步,同时这个接口也实现了 IDispose 接口,从开始使用 using 就可以看出其含义。
参考其引用,可以发现有一个 IUnitOfWork
接口继承自它,并且还有一个 InnerUnitOfWorkCompleteHandle
的内部实现。这里先查看 InnerUnitOfWorkCompleteHandle
内部实现:
internal class InnerUnitOfWorkCompleteHandle : IUnitOfWorkCompleteHandle { public const string DidNotCallCompleteMethodExceptionMessage = "Did not call Complete method of a unit of work."; private volatile bool _isCompleteCalled; private volatile bool _isDisposed; public void Complete() { _isCompleteCalled = true; } public Task CompleteAsync() { _isCompleteCalled = true; return Task.FromResult(0); } public void Dispose() { if (_isDisposed) { return; } _isDisposed = true; if (!_isCompleteCalled) { if (HasException()) { return; } throw new AbpException(DidNotCallCompleteMethodExceptionMessage); } } private static bool HasException() { try { return Marshal.GetExceptionCode() != 0; } catch (Exception) { return false; } } }
其内部实现十分简单,其中 Complete 的同步和异步方法都只是对完成标识进行一个标记。并未真正的进行任何数据库事务操作。同时在他的内部也实现了 IDispose
接口,如果 complete 未被标记为已完成,那么直接抛出异常,后续操作不会执行。
现在再转到 Begin 方法内部就可以发现,在创建的时候会首先判断了当前是否已经存在了工作单元,如果存在了才会创建这样一个内部工作单元。也就是说真正那个的事务操作是在返回的 IUnitOfWork 当中实现的。
这样的话就会构建出一个嵌套的工作单元:
OuterUOW->InnerUow1->InnerUOW2->.....->InnerUowN
你可以想象有以下代码:
public void TestUowMethod() { using(var outerUOW = Manager.Begin()) // 这里返回的是 IOC 解析出的 IUnitOfWork { OperationOuter(); using(var innerUOW1 = Manager.Begin()) // 内部 UOW { Operation1(); using(var innerUOW2 = Manager.Begin()) // 内部 UOW { Operation2(); Complete(); } Complete(); } Complete(); } }
当代码执行的时候,如同俄罗斯套娃,从内部依次到外部执行,内部工作单元仅会在调用 Complete 方法的时候将 completed 标记为 true,但一旦操作抛出异常,Complete无法得到执行,则会直接抛出异常,中断外层代码执行。
那么 IUnitOfWork 的实现又是怎样的呢?
在 ABP 内部针对 EF Core 框架实现了一套 UOW,其继承自 UnitOfWorkBase,而在 UnitOfWorkBase 内部有部分针对接口 IActiveUnitOfWork 的实现,同时由于 IUnifOfWork 也实现了 IUnitOfWorkCompleteHandle 接口,所以在 Begin 方法处能够向上转型。
在 IActiveUnitOfWork 接口当中定义了工作单元的三个事件,用户在使用的时候可以针对这三个事件进行绑定。
| 事件名称 | 触发条件 |
| ------- | --------- |
| Completed | 工作单元调用 Complete 方法之后触发 |
| Failed | 工作单元在调用 Complete 方法如果产生异常,则会在 Dispose 释放资源时触发。 |
| Disposed | 释放工作单元的时候触发 |
除了三个事件之外,在 ABP 当中的数据过滤器也是在工作单元调用的时候工作的,后面讲解 EfCoreUnitOfWork 的时候会研究,数据过滤仅包括软删除等审计字段,同时也包括多租户的租户 ID 也在工作单元当中进行设置的。
在这里也定义了两个 SaveChanges 方法,一个同步、一个异步,作用跟实体上下文的同名方法作用差不多。
IUnitOfWork 同时继承了 IUnitOfWorkCompleteHandle 与 IActiveUnitOfWork 接口,并且增加了两个属性与一个 Begin 方法。
UnitOfWorkBase 是所有工作单元的一个抽象基类,在其内部实现了 IUnitOfWork 的所有方法,其中也包括两个父级接口。
下面就一个一个属性讲解。
这个 Id 是在构造函数当中初始化的,全局唯一的 Id,使用 Guid 初始化其值。
用于标明当前工作单元的外部工作单元,其值是在 UnitOfWorkManager 创建工作单元的时候赋予的。在 Manager 的 Begin 方法当中每次针对 Current Uow 赋值的时候都会将已经存在的 UOW 关联最新的 Current Uow 的 Outer 属性上面。形成如下结构:
Current Uow = Uow3.Outer = Uow2.Outer = Uow1.Outer = null
具体代码参考 ICurrentUnitOfWorkProvider
的实现。
在 Manager 创建好一个 Uow 之后,就会调用它的 Begin 方法,在内部首先做了一个判断,判断是否多次调用了 Begin 方法,这里可以看到并未做加锁处理。这是因为在 ABP 当中,一个线程当中共用一个工作单元。其实在 CurrentProvider 的代码当中就可以看出来如果在一个线程里面创建了多个工作单元,他会将其串联起来。
之后设置过滤器,并且开始调用 BeginUow 方法,这里并未实现,具体实现我们转到 EfUnitOfWork 可以看到。
protected override void BeginUow() { if (Options.IsTransactional == true) { _transactionStrategy.InitOptions(Options); } }
覆写了父类方法,仅对设置进行初始化。
其实到这里我们就大概清楚了 ABP 整个 UOW 的工作流程,如果是两个打上 UnitOfWork 特性的方法在 A 调用 B 的时候其实就会封装成两个嵌套的 using 块。
using(var a = Manager.Begin()) { // 操作 using(var b = Manager.Begin()) { // 操作 b.Complete(); } a.Complete(); }
而最外层的 Complete 就是真正执行了数据库事务操作的。
可以看下 EfUnitOfWork 的实现:
// 这里是 UnitOfWorkBase 的 Complete 方法 public void Complete() { PreventMultipleComplete(); try { CompleteUow(); _succeed = true; OnCompleted(); } catch (Exception ex) { _exception = ex; throw; } }
// 这里是 EfUnitOfWork 的 CompleteUow 方法 protected override void CompleteUow() { SaveChanges(); CommitTransaction(); } // 遍历所有激活的 DbContext 并保存更改到数据库 public override void SaveChanges() { foreach (var dbContext in GetAllActiveDbContexts()) { SaveChangesInDbContext(dbContext); } } // 提交事务 private void CommitTransaction() { if (Options.IsTransactional == true) { _transactionStrategy.Commit(); } }
如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复
Net Core Web Api项目与在NginX下发布的方法
asp.net core3.1 引用的元包dll版本兼容性问题解决方案
IdentityServer4实现.Net Core API接口权限认证(快速入门)
ASP.NET Core MVC通过IViewLocationExpander扩展视图搜索路径的实现
网友评论