使用MediatR时如何通过单事务保存所有变更

你的代码是可行的，核心逻辑完全符合事务原子性的要求——两类任务的保存操作会要么全部提交成功，要么全部回滚，不会出现部分成功的情况。下面具体分析关键细节和可优化点：

核心逻辑的正确性 #

• 你手动创建数据库连接并开启事务，通过命令参数将SqlTransaction传递给两个命令的处理器，确保两个数据库操作共用同一个事务上下文，这是跨MediatR命令实现事务原子性的有效思路。
• try/catch块的提交、回滚逻辑严谨：正常执行完成后提交事务，出现异常时立即回滚并重新抛出异常，保证上层代码能感知到错误并处理。

需要注意的细节与优化建议 #

1. 处理器必须显式使用传入的事务 #

确保两个命令的处理器在执行数据库操作时，必须绑定传入的Transaction对象，不能使用默认的自动提交逻辑。例如在处理器中执行SQL命令时：

// 处理器中的示例代码
await using var command = new SqlCommand("INSERT INTO ...", connection, transaction);
// 执行命令逻辑

如果处理器没有显式关联事务，那么操作会脱离当前事务上下文，原子性无法保证。

2. 连接获取的潜在问题 #

你的代码中_connectionFactory.GetConnectionString方法命名存在歧义——通常这类工厂方法应该返回DbConnection实例而非连接字符串。如果是笔误，需确保获取的是实际的数据库连接对象，否则后续OpenAsync会直接报错。

3. 异常处理的严谨性优化 #

当前catch块会捕获所有异常，但回滚操作本身也可能抛出异常，建议给回滚逻辑单独加一层try/catch，避免覆盖原始业务异常：

catch
{
    try
    {
        await transaction.RollbackAsync(cancellationToken).ConfigureAwait(false);
    }
    catch (Exception rollbackEx)
    {
        // 记录回滚异常，但不覆盖原始异常
        _logger.LogError(rollbackEx, "事务回滚失败");
    }
    throw;
}

4. 用MediatR管道行为简化事务代码 #

如果这类跨命令事务场景较多，可以用MediatR的管道行为(Pipeline Behavior) 封装事务逻辑，避免重复编写连接、事务管理代码。示例如下：

// 定义事务行为
public class TransactionBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
    where TRequest : IRequest<TResponse>, IRequireTransaction
{
    private readonly IDbConnectionFactory _connectionFactory;
    private readonly ILogger<TransactionBehavior<TRequest, TResponse>> _logger;

    public TransactionBehavior(IDbConnectionFactory connectionFactory, ILogger<TransactionBehavior<TRequest, TResponse>> logger)
    {
        _connectionFactory = connectionFactory;
        _logger = logger;
    }

    public async Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next, CancellationToken cancellationToken)
    {
        await using var connection = await _connectionFactory.GetConnectionAsync(cancellationToken).ConfigureAwait(false);
        await connection.OpenAsync(cancellationToken).ConfigureAwait(false);

        await using var transaction = await connection.BeginTransactionAsync(cancellationToken).ConfigureAwait(false);
        request.Transaction = transaction;

        try
        {
            var response = await next().ConfigureAwait(false);
            await transaction.CommitAsync(cancellationToken).ConfigureAwait(false);
            return response;
        }
        catch
        {
            try
            {
                await transaction.RollbackAsync(cancellationToken).ConfigureAwait(false);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "事务回滚失败");
            }
            throw;
        }
    }
}

// 定义需要事务的命令接口
public interface IRequireTransaction
{
    SqlTransaction Transaction { get; set; }
}

// 修改命令实现接口
public record AddTaskType1Command(IEnumerable<TaskType1> tasks1) : IRequest<ErrorOr<Created>>, IRequireTransaction
{
    public SqlTransaction Transaction { get; set; }
}

public record AddTaskType2Command(IEnumerable<TaskType2> tasks2) : IRequest<ErrorOr<Created>>, IRequireTransaction
{
    public SqlTransaction Transaction { get; set; }
}

这种方式可以让命令代码更简洁，事务逻辑统一维护，避免重复造轮子。

总结 #

你的原始代码逻辑是正确的，只要确保处理器正确绑定传入的事务，就能实现两类任务的原子性操作。如果想提升代码复用性和可维护性，推荐使用MediatR管道行为封装事务逻辑。

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