大家好，我是刚子。
做业务开发的时候，经常遇到一个操作要同时更新好几张表的情况。比如保存一张单据，既要写主表，又要写明细，还得写关联条件。这种场景下，要么全部成功，要么全部失败，绝对不能出现"主表存上了，明细丢了"这种半截子事儿。
怎么保证？用事务（Transaction）。
今天刚子就拿一个"凭证规则保存"的真实例子，跟你聊聊 TransactionScope 怎么用、try-catch 放哪儿最合适，顺便总结一套能直接抄的最佳实践。
1. 业务场景：保存一个"凭证规则"
我们要保存的东西长这样：
- 一条主表 记录（
fin_voucher_rule_master） - 多条明细 记录（
fin_voucher_rule_detail） - 每条明细下面还有多条条件 记录（
fin_voucher_rule_condition）
保存有两种情况：
- 新增：主表 ID 为 0，插入主表、明细、条件。
- 更新 ：主表 ID 不为 0。更新主表字段，然后删掉旧的明细和条件，再重新插入新的（这叫"全量替换"模式）。
要求很明确：要么全成，要么全败，不允许半截数据。
2. 最终代码（可以直接用的版本）
下面就是优化后的 Service 层代码。你先看一遍，后面我会拆开讲每一块是干啥的。
csharp
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("更新主表失败");
// 删除旧明细下的所有条件
List<int> 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("删除明细条件失败");
}
// 删除旧明细
List<int> 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.1 TransactionScope 怎么用才正确？
- 必须包在
using块里：这样不管代码正常结束还是抛异常，事务资源都能被释放。 - 只有所有操作成功后，才调用
scope.Complete()：如果中途任何一步失败直接return，using块结束时事务会自动回滚。 - 不需要手动写
Rollback：没调用Complete就等于回滚，代码更干净。
3.2 try-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 写法类似：
csharp
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，性能差，还容易死锁。建议显式指定为 ReadCommitted：
csharp
var 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）。如果明细数量很多，会产生大量数据库往返。优化方案：写一个批量插入方法，接收 List<fin_voucher_rule_detail>，内部只调用一次 SaveChanges。
4.3 并发冲突怎么处理？
更新模式下，如果两个人同时改同一条规则，后提交的人会直接覆盖前面人的修改。解决办法：加一个乐观锁字段（比如 RowVersion），更新时检查版本号，如果不一致就抛异常，让用户刷新后重试。
5. 总结：事务与异常处理的最佳实践清单
| 实践项 | 说明 |
|---|---|
使用 using (TransactionScope) |
确保资源释放和自动回滚 |
把 try-catch 放在事务块内部 |
方便异常后做补偿操作 |
所有数据库操作成功后调用 scope.Complete() |
否则事务自动回滚 |
| 检查每个 DAL 调用的返回值 | 避免静默失败导致部分提交 |
| 不要向外抛出内部异常消息 | 用户只看到友好的通用提示 |
| 记录详细异常日志 | 方便你自己排查问题 |
| 显式指定合理的隔离级别 | 提升并发性能 |
| 预加载需要的导航属性 | 避免 DbContext 释放后延迟加载失败 |
照着这个清单写代码，你的数据持久层会既健壮又好维护。本文的凭证规则保存例子，是一个典型的"主表+明细+子明细"事务场景。掌握了这些技巧，类似的需求你都能轻松拿下。
如果你觉得有用，点个赞，转发给还在被事务折磨的兄弟。
我是刚子，一个写了六年 .NET 代码的程序员。咱们下回见！