.NET 数据库事务的各种玩法进化

事务是数据库系统中的重要概念，本文讲解作者从业 CRUD 十余载的事务多种使用方式总结。

以下所有内容都是针对单机事务而言,不涉及分布式事务相关的东西!
关于事务原理的讲解不针对具体的某个数据库实现,所以某些地方可能和你的实践经验不符。

认识事务

为什么需要数据库事务？

转账是生活中常见的操作,比如从A账户转账100元到B账号。站在用户角度而言,这是一个逻辑上的单一操作,然而在数据库系统中,至少会分成两个步骤来完成：

1.将A账户的金额减少100元

2.将B账户的金额增加100元。

在这个过程中可能会出现以下问题:

1.转账操作的第一步执行成功,A账户上的钱减少了100元,但是第二步执行失败或者未执行便发生系统崩溃,导致B账户并没有相应增加100元。

2.转账操作刚完成就发生系统崩溃,系统重启恢复时丢失了崩溃前的转账记录。

3.同时又另一个用户转账给B账户,由于同时对B账户进行操作,导致B账户金额出现异常。

为了便于解决这些问题,需要引入数据库事务的概念。

以上内容引用自：https://www.cnblogs.com/takumicx/p/9998844.html

认识 ADO.NET

ADO.NET是.NET框架中的重要组件，主要用于完成C#应用程序访问数据库。

ADO.NET的组成：

System.Data.Common → 各种数据访问类的基类和接口

System.Data.SqlClient → 对Sql Server进行操作的数据访问类

a) SqlConnection → 数据库连接器

b) SqlCommand → 数据库命名对象

d) SqlDataReader → 数据读取器

f) SqlParameter → 为存储过程定义参数

g) SqlTransaction → 数据库事物

事务1：ADO.NET

最原始的事务使用方式，缺点：

代码又臭又长
逻辑难控制，一不小心就忘了提交或回滚，随即而来的是数据库锁得不到释放、或者连接池不够用
跨方法传递 Tran 对象太麻烦

事务2：SqlHepler

原始 ADO.NET 事务代码又臭又长，是时候封装一个 SqlHelper 来操作 ADO.NET 了。比如：

SqlHelper.ExecuteNonQuery(...);

SqlHelper.ExecuteScaler(...);

这样封装之后对单次命令执行确实方法不了少，用着用着又发现，事务怎么处理？重截一个 IDbTransaction 参数传入吗？比如：

SqlHelper.ExecuteNonQuery(tran, ...);

SqlHelper.ExecuteScaler(tran, ...);

事务3：利用线程id

在早期 .NET 还没有异步方法的时候，对事务2的缺陷进行了简单封装，避免事务 tran 对象传来传去的问题。

其原因是利用线程id，在事务开启之时保存到 staic Dictionary<int, IDbTransaction> 之中，在 SqlHelper.ExecuteXxx 方法执行之前获取当前线程的事务对象，执行命令。

这样免去了事务传递的恶梦，最终呈现的事务代码如下：

SqlHelper.Transaction(() =>

{

    SqlHelper.ExecuteNonQuery(...); //不再需要显式传递 tran

    SqlHelper.ExecuteScaler(...);

});

这种事务使用起来非常简单，不需要考虑事务提交/释放问题，被默认应用在了 FreeSql 中，缺点：不支持异步。

事务4：工作单元

显式将 ITransaction 对象传来传去，说直接点像少女没穿衣服街上乱跑一样，不安全。而且到时候想给少女带点货（状态），一丝不挂没穿衣服咋带货（没口袋）。

这个时候对 ITransaction 做一层包装就显得有必要了，在IUnitOfWork 中可以定义更多的状态属性。

事务5：AOP 事务

技术不断在发展，先来一堆理论：

以下内容引用自：https://www.cnblogs.com/zhugenqiang/archive/2008/07/27/1252761.html

AOP（Aspect-Oriented Programming，面向方面编程），可以说是OOP（Object-Oriented Programing，面向对象编程）的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切（cross-cutting）代码，在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。

而AOP技术则恰恰相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。AOP代表的是一个横向的关系，如果说“对象”是一个空心的圆柱体，其中封装的是对象的属性和行为；那么面向方面编程的方法，就仿佛一把利刃，将这些空心圆柱体剖开，以获得其内部的消息。而剖开的切面，也就是所谓的“方面”了。然后它又以巧夺天功的妙手将这些剖开的切面复原，不留痕迹。

使用“横切”技术，AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。比如权限认证、日志、事务处理。Aop 的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。正如Avanade公司的高级方案构架师Adam Magee所说，AOP的核心思想就是“将应用程序中的商业逻辑同对其提供支持的通用服务进行分离。”

实现AOP的技术，主要分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；二是采用静态织入的方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码。

最终呈现的使用代码如下：

[Transactional]

public void SaveOrder()

{

    SqlHelper.ExecuteNonQuery(...);

    SqlHelper.ExecuteScaler(...);

}

事务6：UnitOfWorkManager

推荐：★★★★★

（事务5）声明式事务管理在底层是建立在 AOP 的基础之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。

声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明（或通过等价的基于标注的方式），便可以将事务规则应用到业务逻辑中。因为事务管理本身就是一个典型的横切逻辑，正是 AOP 的用武之地。

通常情况下，笔者强烈建议在开发中使用声明式事务，不仅因为其简单，更主要是因为这样使得纯业务代码不被污染，极大方便后期的代码维护。

和编程式事务相比，声明式事务唯一不足地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。

事务6 UnitOfWorkManager 参考隔壁强大的 java spring 事务管理机制，事务5只能定义单一事务行为（比如不能嵌套），事务5实现的行为机制如下：

六种传播方式(propagation)，意味着跨方法的事务非常方便，并且支持同步异步：

Requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，默认的选择。
Supports：支持当前事务，如果没有当前事务，就以非事务方法执行。
Mandatory：使用当前事务，如果没有当前事务，就抛出异常。
NotSupported：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
Never：以非事务方式执行操作，如果当前事务存在则抛出异常。
Nested：以嵌套事务方式执行。

参考 FreeSql 的使用方式如下：

第一步：配置 Startup.cs 注入

//Startup.cs

public void ConfigureServices(IServiceCollection services)

{

    services.AddSingleton<IFreeSql>(fsql);

    services.AddScoped<UnitOfWorkManager>();

    services.AddFreeRepository(null, typeof(Startup).Assembly);

}

UnitOfWorkManager 成员	说明
IUnitOfWork Current	返回当前的工作单元
void Binding(repository)	将仓储的事务交给它管理
IUnitOfWork Begin(propagation, isolationLevel)	创建工作单元

第二步：定义事务特性

[AttributeUsage(AttributeTargets.Method)]

public class TransactionalAttribute : Attribute

{

    /// <summary>

    /// 事务传播方式

    /// </summary>

    public Propagation Propagation { get; set; } = Propagation.Requierd;

    /// <summary>

    /// 事务隔离级别

    /// </summary>

    public IsolationLevel? IsolationLevel { get; set; }

}

第三步：引入动态代理库

在 Before 从容器中获取 UnitOfWorkManager，调用它的 var uow = Begin(attr.Propagation, attr.IsolationLevel) 方法

在 After 调用 Before 中的 uow.Commit 或者 Rollback 方法，最后调用 uow.Dispose

第四步：在 Controller 或者 Service 或者 Repository 中使用事务特性

public class SongService

{

    BaseRepository<Song> _repoSong;

    BaseRepository<Detail> _repoDetail;

    SongRepository _repoSong2;

    public SongService(BaseRepository<Song> repoSong, BaseRepository<Detail> repoDetail, SongRepository repoSong2)

    {

        _repoSong = repoSong;

        _repoDetail = repoDetail;

        _repoSong2 = repoSong2;

    }

    [Transactional]

    public virtual void Test1()

    {

        //这里 _repoSong、_repoDetail、_repoSong2 所有操作都是一个工作单元

        this.Test2();

    }

    [Transactional(Propagation = Propagation.Nested)]

    public virtual void Test2() //嵌套事务，新的（不使用 Test1 的事务）

    {

        //这里 _repoSong、_repoDetail、_repoSong2 所有操作都是一个工作单元

    }

}

问题：是不是进方法就开事务呢？

不一定是真实事务，有可能是虚的，就是一个假的 unitofwork（不带事务）。

也有可能是延用上一次的事务。

也有可能是新开事务，具体要看传播模式。

结束语

技术不断的演变进步，从 1.0 -> 10.0 需要慢长的过程。

同时呼吁大家不要盲目使用微服务，演变的过程周期漫长对项目的风险太高。

早上五点半醒来，写下本文对事务理解的一点总结。谢谢！！

以上各种事务机制在 FreeSql 中都有实现，FreeSql 是功能强大的对象关系映射技术(O/RM)，支持 .NETCore 2.1+ 或 .NETFramework 4.0+ 或 Xamarin。支持 MySql/SqlServer/PostgreSQL/Oracle/Sqlite/达梦/人大金仓/神舟通用/Access；单元测试数量 5000+，以 MIT 开源协议托管于 github：https://github.com/dotnetcore/FreeSql