在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只是基于事务补偿的思路,即本服务中,跨服务调用失败,本服务中的操作不会自动回滚,而是通过消息队列去尝试跨服务操作的补偿,最终达到操作数据的完整性。

 

posted @ 2019-07-01 18:27  上盐码农  阅读(1995)  评论(1编辑  收藏  举报