Asp.Net MVC5中多服务共享DbContext实例的设计合理性探讨

一、当前实现是否属于不良设计？ #

是的，这属于不良设计。你的业务逻辑正确性完全依赖于DI容器对DbContext的生命周期配置（必须是单例/请求级单例，保证所有服务共享同一实例），这种依赖是隐性的：

• 后续如果有人调整DI配置（比如误将DbContext改成瞬态），事务逻辑会直接失效，且很难快速定位问题；
• 代码本身没有显式声明这种依赖，可读性和可维护性差，新接手的开发者可能意识不到这个隐藏约束。

二、更合理的解决方案 #

方案1：显式传递DbContext到服务方法 #

这是改动最小、最直观的方案，直接修改ServiceA和ServiceB的Db操作方法，让它们接收DbContext参数，彻底消除对DI配置的依赖：

// ServiceA修改后的代码
public class ServiceA
{
    // 移除构造函数注入的DbContext
    public void DoSomethingThatInvolvesDbContext1(DbContext context)
    {
        // 使用传入的context执行数据库操作
        context.Set<SomeEntity>().Add(new SomeEntity());
        context.SaveChanges();
    }
}

// ServiceC修改后的代码
public class ServiceC
{
    private readonly DbContext _context;
    private readonly ServiceA _serviceA;
    private readonly ServiceB _serviceB;

    public ServiceC(DbContext context, ServiceA serviceA, ServiceB serviceB)
    {
        _context = context;
        _serviceA = serviceA;
        _serviceB = serviceB;
    }
    
    public void DoSomething()
    {
        using var transaction = _context.Database.BeginTransaction();
        try
        {
            // 显式传递当前DbContext给其他服务
            _serviceA.DoSomethingThatInvolvesDbContext1(_context);
            _serviceB.DoSomethingThatInvovlesDbContext2(_context);
            
            transaction.Commit();
        }
        catch
        {
            transaction.Rollback();
            throw;
        }
    }
}

方案2：引入工作单元模式（Unit of Work） #

如果项目后续有更多事务或DbContext管理需求，可以封装一个简单的工作单元，统一管理DbContext和事务，让所有服务依赖工作单元而非直接依赖DbContext：

// 定义工作单元接口
public interface IUnitOfWork : IDisposable
{
    DbContext Context { get; }
    void BeginTransaction();
    void Commit();
    void Rollback();
}

// 工作单元实现
public class UnitOfWork : IUnitOfWork
{
    private readonly DbContext _context;
    private DbContextTransaction _transaction;

    public UnitOfWork(DbContext context)
    {
        _context = context;
    }

    public DbContext Context => _context;

    public void BeginTransaction()
    {
        _transaction = _context.Database.BeginTransaction();
    }

    public void Commit()
    {
        _transaction?.Commit();
        _context.SaveChanges();
    }

    public void Rollback()
    {
        _transaction?.Rollback();
    }

    public void Dispose()
    {
        _transaction?.Dispose();
        _context.Dispose();
    }
}

// ServiceA依赖工作单元
public class ServiceA
{
    private readonly IUnitOfWork _unitOfWork;

    public ServiceA(IUnitOfWork unitOfWork)
    {
        _unitOfWork = unitOfWork;
    }

    public void DoSomethingThatInvolvesDbContext1()
    {
        // 通过工作单元获取DbContext
        _unitOfWork.Context.Set<SomeEntity>().Add(new SomeEntity());
    }
}

// ServiceC依赖工作单元
public class ServiceC
{
    private readonly IUnitOfWork _unitOfWork;
    private readonly ServiceA _serviceA;
    private readonly ServiceB _serviceB;

    public ServiceC(IUnitOfWork unitOfWork, ServiceA serviceA, ServiceB serviceB)
    {
        _unitOfWork = unitOfWork;
        _serviceA = serviceA;
        _serviceB = serviceB;
    }
    
    public void DoSomething()
    {
        _unitOfWork.BeginTransaction();
        try
        {
            _serviceA.DoSomethingThatInvolvesDbContext1();
            _serviceB.DoSomethingThatInvovlesDbContext2();
            
            _unitOfWork.Commit();
        }
        catch
        {
            _unitOfWork.Rollback();
            throw;
        }
    }
}

然后在DI容器中配置IUnitOfWork为请求级生命周期（和DbContext保持一致），这样所有服务都会共享同一个工作单元内的DbContext，事务逻辑不再依赖隐性的DI配置。

方案3：简化版工厂模式（避免过度设计） #

如果不想修改现有服务的方法签名，可以用静态创建方法替代复杂的工厂接口，保证服务使用指定的DbContext：

// ServiceA添加静态创建方法
public class ServiceA
{
    private readonly DbContext _context;

    // 私有构造函数，强制通过静态方法创建
    private ServiceA(DbContext context)
    {
        _context = context;
    }

    public static ServiceA Create(DbContext context)
    {
        return new ServiceA(context);
    }

    public void DoSomethingThatInvolvesDbContext1()
    {
        // 业务逻辑
    }
}

// ServiceC中直接创建服务实例
public class ServiceC
{
    private readonly DbContext _context;
    private readonly ServiceA _serviceA;
    private readonly ServiceB _serviceB;

    public ServiceC(DbContext context)
    {
        _context = context;
        _serviceA = ServiceA.Create(context);
        _serviceB = ServiceB.Create(context);
    }
    
    // 事务逻辑保持不变
}

三、方案选择建议 #

• 优先选方案1：改动最小，代码逻辑清晰，完全消除隐性依赖；
• 如果项目有长期维护需求，考虑方案2：统一管理DbContext和事务，提升代码的可扩展性；
• 方案3仅作为过渡方案，适合不想大规模修改现有代码的场景。

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