EF Core中SavedChanges与TransactionCommitting拦截的差异及审计日志应用

一、触发时机不一样 #

• SavedChanges()：等SaveChanges/SaveChangesAsync所有操作彻底跑完才触发——包括所有变更写入数据库，要是有事务的话，事务也已经提交成功了。简单说就是，数据库里的数据已经完全更新好了，这个方法才会执行。
• TransactionCommitting()：在事务要提交但还没提交完的时候触发。EF已经给数据库发了提交请求，但数据库还没最终确认成功，处于提交流程的中间环节。

二、适用场景有区别 #

• SavedChanges()：不管你用不用显式事务，只要调用SaveChanges就会触发。比如单个SaveChanges操作（EF自动管的隐式事务），或者你自己开了显式事务、提交之后，都会触发它。它跟事务存不存在没关系，只看SaveChanges有没有做完。
• TransactionCommitting()：只有当你用显式事务（比如通过BeginTransaction开启的事务）的时候才会触发。要是用的是EF自动处理的隐式事务（单个SaveChanges默认的那种），这个拦截方法根本不会被调用。

三、数据状态的可靠性不同 #

• SavedChanges()：到这个阶段，数据库里的变更已经100%生效了，事务也稳了。这时候记录审计日志，绝对不会出现“日志写了但变更被回滚”的情况，日志和实际数据是完全一致的。
• TransactionCommitting()：这时候事务还在提交路上，万一数据库崩了、网络断了，事务可能会失败回滚。要是这时候写了审计日志，就会出现“日志有记录，但实际数据库没变更”的矛盾情况。

四、针对你的审计日志需求的建议 #

你要把审计日志存到非数据库存储，核心肯定是要日志和数据库变更对应上，不能有偏差。这种情况下，优先用SavedChanges()就对了——它能保证只有变更确实成功了，才会记录日志，不会出问题。

除非你的业务能接受极小概率的日志超前记录（比如事务提交失败但日志已经写了），否则别用TransactionCommitting()。

内容的提问来源于stack exchange，提问作者Sora Teichman