大家好，我是刚子。

做业务开发的时候，经常遇到一个操作要同时更新好几张表的情况。比如保存一张单据，既要写主表，又要写明细，还得写关联条件。这种场景下，要么全部成功，要么全部失败，绝对不能出现“主表存上了，明细丢了”这种半截子事儿。

怎么保证？用事务（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("更新主表失败");

                // 删除旧明细下的所有条件
                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 写法类似：

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：

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 代码的程序员。咱们下回见！