EF Core+Clean Architecture架构下如何规范调用存储过程不破坏原有架构

存储过程调用层选择 #

存储过程的调用逻辑放在 Repository层 实现，完全符合你提到的所有架构约束：

• 符合Repository封装数据访问逻辑的定位，所有数据库交互逻辑都收拢在Repository，避免Service层直接接触DbContext
• 遵守「Repository不执行提交操作」的约束，仅把存储过程调用注册到当前UOW的事务上下文，最终提交还是交给UOW的CompeleteAsync方法统一处理

具体实现步骤 #

1. 扩展仓储接口 #

首先在IUserRepository中添加存储过程对应的方法签名：

public interface IUserRepository
{
    // 保留原有所有方法
    Task AddViaStoredProcedure(User user);
}

2. 在UserRepository中实现方法 #

注意此处仅调用存储过程，不执行提交操作：

public async Task AddViaStoredProcedure(User user)
{
    var sqlParams = new[]
    {
        new SqlParameter("@Email", user.Email),
        // 补充存储过程需要的其他参数
    };
    // 仅把存储过程调用加入当前DbContext事务队列，不做提交
    await _dbContext.Database.ExecuteSqlRawAsync("EXEC InsertUser @Email, @其他参数名", sqlParams);
}

此处完全符合约束：没有在Repository中执行Save/Commit操作，也没有把DbContext暴露给上层Service。

3. Service层调用（和原有逻辑完全兼容） #

Service层不需要感知底层是EF原生写入还是存储过程，调用逻辑和原有写法保持一致：

public async Task RegisterUser(UserAddVM userAddVM)
{           
    var user = await _unitOfWork.Users.GetByEmail(userAddVM.Email);
    if (user != null)
    {
        // 保留原有重复用户处理逻辑
    }             
    else {
        var u = new User
        {
            Email = userAddVM.Email,
            // 补充其他属性赋值
        };
        // 仅需把原有Add方法替换为存储过程对应的方法即可
        await _unitOfWork.Users.AddViaStoredProcedure(u);
        // 仍由UOW统一提交，保证事务一致性
        await _unitOfWork.CompeleteAsync();              
    }
}

特殊场景适配 #

如果调用的存储过程需要返回输出参数（比如自动生成的用户ID），可以直接在Repository的实现方法中接收返回值，再返回给Service层即可，不需要调整现有架构。
如果存储过程内部自带事务提交逻辑，需要提前做好事务兼容处理，避免和UOW的外层事务产生冲突。
所有原生SQL/存储过程调用必须使用参数化传参，避免SQL注入风险。

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