在ABP代码项目中使用CAP进行分布式事务处理
先准备好一个ABP模板代码解决方案,按DotnetCore.CAP的使用教程。
代码跑起
abp的windsor castle DI 容器,并没有注入DbContext的实例,这是必然的,ABP 的Dbcontext是靠 addabp() 注入到 DI 容器中。因此想要向ServiceCollection注入CAP服务,并且还期望使用EF,在ABP框架中并不支持。这是注入的一个先后问题,因为addcap()成功的前提是必须在ServiceProvider中能够把 DbContext的实例反射拿到手。
且看CAP的源码
那么该咋办呢?
可以直接引用数据库连接字符串,这样就不须dbcontext实例了。
接下来,是事务的处理了。
按CAP教程是这样的,给了一个ado.net,一个EF的例子。
https://github.com/dotnetcore/CAP
既然EF是用不了了,那就尝试用dapper。
https://aspnetboilerplate.com/Pages/Documents/Dapper-Integration
定义了一个dappermodule, 在ABP的application应用层模块中注入了这个模块。
public class SomeApplicationService : ITransientDependency { private readonly IDapperRepository<Person> _personDapperRepository; private readonly IRepository<Person> _personRepository; public SomeApplicationService( IRepository<Person> personRepository, IDapperRepository<Person> personDapperRepository, ICapPublisher capPublisher) { _personRepository = personRepository; _personDapperRepository = personDapperRepository; _capBus = capPublishe; } public void DoSomeStuff() { var people = _personDapperRepository.Query("select * from Persons"); await _capBus.PublishAsync("othersystem.aftergetperson", input); } }
因为在ABP的applicationservice中的方法,默认是自带unitofwork的,所以代码中无须再用事务代码块。
总结:在使用CAP的时候,最开始的目标是想着分布式事务能够支持自动回滚,也就是在本服务中,跨服务调用失败,本服务的操作能够回滚。但经过一番了解,这只是我的一厢情愿,真的要达到这个目标,代价肯定是昂贵的。CAP只是基于事务补偿的思路,即本服务中,跨服务调用失败,本服务中的操作不会自动回滚,而是通过消息队列去尝试跨服务操作的补偿,最终达到操作数据的完整性。