C#事务处理最佳实践：别再让“主表存了、明细丢了”的破事发生

大家好我是刚子。做业务开发的时候经常遇到一个操作要同时更新好几张表的情况。比如保存一张单据既要写主表又要写明细还得写关联条件。这种场景下要么全部成功要么全部失败绝对不能出现“主表存上了明细丢了”这种半截子事儿。怎么保证用事务Transaction。今天刚子就拿一个“凭证规则保存”的真实例子跟你聊聊TransactionScope怎么用、try-catch放哪儿最合适顺便总结一套能直接抄的最佳实践。1. 业务场景保存一个“凭证规则”我们要保存的东西长这样一条主表记录fin_voucher_rule_master多条明细记录fin_voucher_rule_detail每条明细下面还有多条条件记录fin_voucher_rule_condition保存有两种情况新增主表 ID 为 0插入主表、明细、条件。更新主表 ID 不为 0。更新主表字段然后删掉旧的明细和条件再重新插入新的这叫“全量替换”模式。要求很明确要么全成要么全败不允许半截数据。2. 最终代码可以直接用的版本下面就是优化后的 Service 层代码。你先看一遍后面我会拆开讲每一块是干啥的。public static OperationResult SaveVoucher_Rule_Master(fin_voucher_rule_master master){ using (var scope new TransactionScope()) { try { // ----- 1. 新增或更新主表 ----- if (master.Id 0) { // 新增主表 int id DAL.VoucherRuleMasterDAL.Add(master); if (id 0) return OperationResult.Fail(添加主表失败); master.Id id; // 把数据库生成的自增ID回填到实体 } else { // 更新模式先查出旧的完整数据含明细和条件 var existingMaster DAL.VoucherRuleMasterDAL.GetFin_Voucher_Rule_Master(master.Id); if (existingMaster null) return OperationResult.Fail(未找到要更新的记录); // 更新主表字段把前端传的值赋给查出来的实体 existingMaster.business_type master.business_type; existingMaster.rule_code master.rule_code; // ... 其他字段赋值省略 bool updateOk DAL.VoucherRuleMasterDAL.EditFin_Voucher_Rule_Master(existingMaster); if (!updateOk) return OperationResult.Fail(更新主表失败); // 删除旧明细下的所有条件 Listint conditionIds existingMaster.fin_voucher_rule_detail .SelectMany(d d.fin_voucher_rule_condition) .Select(c c.Id).ToList(); if (conditionIds.Any()) { bool delCondOk DAL.VoucherRuleMasterDAL.DeleteFin_Voucher_Rule_Conditions(conditionIds); if (!delCondOk) return OperationResult.Fail(删除明细条件失败); } // 删除旧明细 Listint detailIds existingMaster.fin_voucher_rule_detail.Select(d d.Id).ToList(); if (detailIds.Any()) { bool delDetailOk DAL.VoucherRuleMasterDAL.DeleteFin_Voucher_Rule_Details(detailIds); if (!delDetailOk) return OperationResult.Fail(删除明细失败); } } // ----- 2. 插入新的明细和条件 ----- foreach (var detail in master.fin_voucher_rule_detail) { detail.rule_id master.Id; // 关联主表ID int detailId DAL.VoucherRuleMasterDAL.AddFin_Voucher_Rule_Detail(detail); if (detailId 0) return OperationResult.Fail(添加明细失败); // 把明细ID回填到每个条件 foreach (var condition in detail.fin_voucher_rule_condition) { condition.detail_id detailId; } bool addCondOk DAL.VoucherRuleMasterDAL.AddFin_Voucher_Rule_Conditions(detail.fin_voucher_rule_condition.ToList()); if (!addCondOk) return OperationResult.Fail(添加明细条件失败); } // ----- 3. 所有操作成功提交事务 ----- scope.Complete(); return OperationResult.Success(保存成功); } catch (Exception ex) { // 事务会自动回滚因为没调用 Complete // 这里记录详细日志示例省略正式项目必须加上 return OperationResult.Fail(系统错误请稍后重试); } }}补充说明DAL 层方法返回int新增时返回自增ID或bool更新/删除是否成功并且不会在内部吞掉异常要么向上抛要么返回明确状态。3. 核心设计要点看完就懂为什么要这么写3.1TransactionScope怎么用才正确必须包在using块里这样不管代码正常结束还是抛异常事务资源都能被释放。只有所有操作成功后才调用scope.Complete()如果中途任何一步失败直接returnusing块结束时事务会自动回滚。不需要手动写Rollback没调用Complete就等于回滚代码更干净。3.2try-catch应该放在事务里面还是外面答案是放里面就像上面的代码一样。理由放里面可以捕获异常后做额外操作比如记日志记到非事务表或者写文件。放里面能明确区分“业务逻辑返回失败”和“系统异常”。前者用OperationResult.Fail正常返回后者用catch兜底。如果把try-catch包在整个using外面效果也差不多但你在catch里想访问事务相关的资源就不太方便。所以推荐把catch放在using块内部。3.3 每个 DAL 调用的返回值都要检查不能偷懒DAL 返回0或false表示操作失败。Service 层必须挨个检查一旦失败就立即停止并返回错误。这是保证事务原子性的关键。如果不检查失败了还继续往下走最后调用Complete()就会导致“部分成功”的灾难。你看代码里每一处 DAL 调用后都有if (!ok) return Fail(...)这就是守卫代码。3.4 主键回填小细节大作用新增主表后数据库生成的自增 ID 必须马上赋给master.Id。因为后面插入明细的时候需要detail.rule_id master.Id。如果你忘了回填master.Id还是 0明细就关联不上了。3.5 导航属性要提前加载否则会踩坑在更新模式里我们调用了GetFin_Voucher_Rule_Master(master.Id)。这个方法内部必须用Include把明细和条件一起查出来否则后面访问existingMaster.fin_voucher_rule_detail的时候可能会因为 DbContext 已经释放或者延迟加载失败而报错。正确的 DAL 写法类似public static fin_voucher_rule_master GetFin_Voucher_Rule_Master(int id){ using (var db new PcbEntities()) { return db.fin_voucher_rule_master .Include(x x.fin_voucher_rule_detail.Select(d d.fin_voucher_rule_condition)) .FirstOrDefault(x x.Id id); }}3.6 不要把异常消息直接扔给用户catch块里返回系统错误请稍后重试而不是ex.Message。这样做有两个好处不泄露敏感信息比如 SQL 语句、数据库连接串。用户体验好看到一堆英文报错会慌。详细的异常信息应该记到日志文件或日志表里方便你自己排查问题。4. 进阶建议让代码更专业4.1 指定事务隔离级别TransactionScope默认的隔离级别是Serializable性能差还容易死锁。建议显式指定为ReadCommittedvar options new TransactionOptions{ IsolationLevel IsolationLevel.ReadCommitted, Timeout TimeSpan.FromMinutes(1)};using (var scope new TransactionScope(TransactionScopeOption.Required, options)){ // ...}4.2 避免循环里多次SaveChanges当前代码中每个明细插入都单独调用一次AddFin_Voucher_Rule_Detail内部会SaveChanges。如果明细数量很多会产生大量数据库往返。优化方案写一个批量插入方法接收Listfin_voucher_rule_detail内部只调用一次SaveChanges。4.3 并发冲突怎么处理更新模式下如果两个人同时改同一条规则后提交的人会直接覆盖前面人的修改。解决办法加一个乐观锁字段比如RowVersion更新时检查版本号如果不一致就抛异常让用户刷新后重试。5. 总结事务与异常处理的最佳实践清单实践项说明使用using (TransactionScope)确保资源释放和自动回滚把try-catch放在事务块内部方便异常后做补偿操作所有数据库操作成功后调用scope.Complete()否则事务自动回滚检查每个 DAL 调用的返回值避免静默失败导致部分提交不要向外抛出内部异常消息用户只看到友好的通用提示记录详细异常日志方便你自己排查问题显式指定合理的隔离级别提升并发性能预加载需要的导航属性避免 DbContext 释放后延迟加载失败照着这个清单写代码你的数据持久层会既健壮又好维护。本文的凭证规则保存例子是一个典型的“主表明细子明细”事务场景。掌握了这些技巧类似的需求你都能轻松拿下。如果你觉得有用点个赞转发给还在被事务折磨的兄弟。我是刚子一个写了六年 .NET 代码的程序员。咱们下回见#csharp #事务处理 #transactionscope #trycatch- - 推荐关注「CSharp精选营」提升编程技能 精选推荐 点击标题可跳转使用 C# 实现23种常见的设计模式 C# WinForms 实现打印监听组件一个基于 .NET 开源、简易、轻量级的进销存管理系统ASP.NET Core Blazor简介和快速入门一基础篇ZR.Admin.NET为.NET开发者打造的效率利器一站式企业级后台开源框架ML.NET 快速入门与实践教程机器学习框架OpenClaw现象级爆红AI智能体的“事实标准”如何改变我们的开发方式.NET面试经典三问什么是.NET、.NET Framework、.NET Core?及相关引申问题都是微软亲儿子WPF凭啥干不掉WinForm这3个场景说明白了点赞和在看就是最大的支持❤️