合并Repository逻辑实现Job与Log同步保存的最优方案咨询

结论 #

最推荐的实现方式是引入业务服务层封装事务逻辑，搭配工作单元(UnitOfWork)模式统一管理上下文提交。你列出的三个方案均存在明显缺陷，先逐个说明问题：

• 方案3：完全不可用。首先Controller中没有调用任何Save方法，两条数据都不会持久化到数据库；就算补充两次Save调用，先存Job再存Log的逻辑只要第二次Save抛出异常，就会出现Job已存、Log未存的不一致问题，完全达不到你的需求。
• 方案2：违反单一职责原则。JobRepository的本职是仅处理Job实体的持久化操作，强依赖LogRepository会导致两个Repository高度耦合，后续如果要调整Log生成规则、或者需要单独调用CreateJob不生成Log的场景，都得修改JobRepository代码，可复用性极差。
• 方案1：比前两个方案可用，但架构职责不合理。Controller层的核心职责是处理HTTP请求、参数校验、路由响应，不应该直接依赖DbContext，也不应该承担数据提交的逻辑，如果后续有其他业务场景也需要联动创建Job和Log，这段提交逻辑会重复写多份，维护成本高。

最优方案实现 #

正确的架构分层逻辑为：Repository层仅负责单实体的增删改查操作，不单独实现Save逻辑；新增业务服务层封装跨实体的业务逻辑，统一控制事务提交；如果要进一步解耦DbContext的依赖，可以引入工作单元模式封装上下文的提交操作。

代码示例

1. 工作单元封装：

public interface IUnitOfWork : IDisposable
{
    IJobRepository Jobs { get; }
    ILogRepository Logs { get; }
    int SaveChanges();
    // 扩展显式事务方法，兼容多步提交场景
    void BeginTransaction();
    void CommitTransaction();
    void RollbackTransaction();
}

public class UnitOfWork : IUnitOfWork
{
    private readonly Context _context;
    public IJobRepository Jobs { get; }
    public ILogRepository Logs { get; }

    public UnitOfWork(Context context, IJobRepository jobRepository, ILogRepository logRepository)
    {
        _context = context;
        Jobs = jobRepository;
        Logs = logRepository;
    }

    public int SaveChanges() => _context.SaveChanges();
    public void BeginTransaction() => _context.Database.BeginTransaction();
    public void CommitTransaction() => _context.Database.CommitTransaction();
    public void RollbackTransaction() => _context.Database.RollbackTransaction();
    public void Dispose() => _context.Dispose();
}

2. 业务服务层封装逻辑：

public interface IJobService
{
    void CreateJobWithLog();
}

public class JobService : IJobService
{
    private readonly IUnitOfWork _uow;

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

    public void CreateJobWithLog()
    {
        // 显式开启事务保证一致性，单SaveChanges场景也可省略，开启兼容性更强
        try
        {
            _uow.BeginTransaction();
            var jobId = _uow.Jobs.CreateJob();
            _uow.Logs.CreateLog(jobId);
            _uow.SaveChanges();
            _uow.CommitTransaction();
        }
        catch
        {
            _uow.RollbackTransaction();
            throw;
        }
    }
}

3. Controller层仅处理请求：

public class JobsController : Controller
{
    private readonly IJobService _jobService;

    public JobsController(IJobService jobService)
    {
        _jobService = jobService;
    }

    [HttpGet]
    public IActionResult Create()
    {
        return View();
    }

    [HttpPost]
    public IActionResult Create()
    {
        _jobService.CreateJobWithLog();
        return RedirectToAction("Index");
    }
}

方案优势

1. 职责清晰：Repository只做单实体操作，Service封装业务逻辑，Controller只处理请求，各层职责单一，可维护性强。
2. 数据一致性保障：所有操作在同一个事务内执行，任何一步出错都会全量回滚，不会出现部分保存的问题。
3. 可复用性高：创建Job带Log的逻辑封装在Service里，任何需要该逻辑的场景都可以直接调用，不需要重复写代码。
4. 耦合度低：各层都依赖抽象接口，后续换实现、调整逻辑都不需要修改上层代码，符合开闭原则。

如果你的业务场景非常简单，不想额外引入工作单元模式，退而求其次可以选择方案1，但是要把SaveChanges的逻辑抽到Service层，不要放在Controller里，不推荐使用方案2和3。

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