SaveChanges()方法应置于工作单元(Unit of Work)还是泛型仓储(Generic Repository)中？

这个问题在Repository模式的实际落地中真的挺常见的，我来帮你捋捋思路，结合你的ASP.NET Web API + EF Core场景给出具体建议。

首先得明确两个组件的核心职责：

• 泛型仓储(GenericRepository)：本质是封装单一实体的CRUD操作，它的职责是帮你屏蔽EF Core的具体数据访问细节，让业务层不用直接和DbContext打交道。
• 工作单元(IUnitOfWork)：核心是管理多个仓储的变更，保证事务一致性——简单说就是让一组相关的数据库操作要么全部成功，要么全部回滚。

针对你提到的两个选项，我们逐个分析：

选项1：把Save()放在IUnitOfWork中 #

这其实是符合UoW设计初衷的选择，理由有这些：

• SaveChanges（包括异步版本）的本质是提交所有仓储的变更，这本身就是UoW的核心职责之一，和BeginTransaction、Commit、Rollback是配套的。
• 你担心的“单仓储服务要注入UoW显得冗余”其实不用太在意：依赖注入的开销微乎其微，而且现在是单仓储场景，以后业务复杂度上来了，大概率会遇到需要同时操作多个仓储的情况（比如创建用户的同时添加操作日志），这时候UoW的优势就体现了——一次Save就能保证所有变更的原子性，避免数据不一致。
• 举个实际的代码例子，你的IUnitOfWork可以这么定义：

public interface IUnitOfWork : IDisposable
{
    IGenericRepository<User> UserRepository { get; }
    IGenericRepository<UserLog> UserLogRepository { get; }
    Task BeginTransactionAsync();
    Task CommitAsync();
    Task RollbackAsync();
    Task<int> SaveChangesAsync();
}

服务层调用的时候，不管是单仓储还是多仓储，逻辑都很统一：

public class UserService : IUserService
{
    private readonly IUnitOfWork _uow;

    public UserService(IUnitOfWork uow)
    {
        _uow = uow;
    }

    // 单仓储场景
    public async Task UpdateUserAsync(User user)
    {
        await _uow.UserRepository.UpdateAsync(user);
        await _uow.SaveChangesAsync();
    }

    // 多仓储场景
    public async Task CreateUserWithLogAsync(User user)
    {
        await _uow.UserRepository.AddAsync(user);
        await _uow.UserLogRepository.AddAsync(new UserLog { UserId = user.Id, Action = "Created" });
        // 一次Save提交两个仓储的变更，保证事务一致
        await _uow.SaveChangesAsync();
    }
}

选项2：把Save()放在GenericRepository中 #

这个选择会带来一些潜在问题：

• 如果把Save嵌入到CRUD方法里（比如Add后立刻调用Save），会导致多次不必要的数据库提交——比如一次业务操作要添加10个实体，就会触发10次SaveChanges，性能损耗很明显，而且完全不符合UoW的事务管理逻辑。
• 如果在Repository里单独加一个Save方法，那每个Repository都能独立提交变更，这会直接破坏UoW的设计目的：本来UoW是要统一管理所有变更的，现在各个仓储都能自己提交，事务一致性根本没法保证，万一两个仓储的操作一个成功一个失败，数据就乱了。

另外你提到EF Core本身已经实现了UoW，这点没错——DbContext本身就是一个UoW，它的SaveChanges就是提交所有跟踪的变更。很多时候我们自己封装UoW和Repository，是为了抽象数据访问层，让业务逻辑和EF Core解耦，方便后续更换ORM框架，或者编写单元测试时用Mock替代真实数据库。

总结建议 #

从长远的可维护性、事务一致性和单一职责原则来看，把Save()方法放在IUnitOfWork中是更合理的选择：

• 让Repository专注于单一实体的数据访问操作，不负责变更提交；
• 让UoW统一管理所有变更的提交和事务，保证业务逻辑的原子性；
• 虽然单仓储场景下要注入UoW，但这种“冗余”换来了代码的扩展性和稳定性，完全值得。

备注：内容来源于stack exchange，提问作者Nandan Bhowmick