使用EF Core时不通过仓储层直接将DB Context注入服务层是否是良好实践？

EF Core 自带的DbContext本身已经内置了工作单元（Unit Of Work）与仓储模式的实现，绝大多数普通业务场景下额外封装自定义仓储层都属于冗余设计，只会增加无意义的开发维护成本，你的设计思路完全合理。

具体实现要点 #

• DbContext 生命周期配置：ASP.NET Core 中默认给DbContext注册的是Scoped生命周期，和单次请求、服务层的生命周期完全匹配，单次请求内所有服务操作共享同一个DbContext实例，操作完成后统一调用SaveChanges提交变更，天然符合工作单元的设计要求。
• 服务层职责划分：所有业务规则判断、数据操作逻辑都封装在服务类内部，控制器仅负责参数校验、请求入参转换、调用服务方法、转换服务返回值为响应结果即可，完全可以做到控制器代码轻量化。

代码示例 #

服务注册配置 #

// Program.cs 配置示例
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// 按业务模块注册服务层实例
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddScoped<IUserService, UserService>();

服务层实现示例 #

public class OrderService : IOrderService
{
    private readonly AppDbContext _context;

    // 构造函数直接注入 DbContext
    public OrderService(AppDbContext context)
    {
        _context = context;
    }

    public async Task<OrderDto> CreateOrderAsync(CreateOrderRequest request)
    {
        // 所有业务逻辑直接在服务内实现，直接调用EF Core原生API
        var user = await _context.Users.FirstOrDefaultAsync(u => u.Id == request.UserId);
        if (user == null)
        {
            throw new ArgumentException("用户不存在");
        }

        var newOrder = new Order
        {
            UserId = request.UserId,
            Amount = request.Amount,
            CreatedTime = DateTime.Now
        };
        _context.Orders.Add(newOrder);
        
        // 统一提交变更
        await _context.SaveChangesAsync();

        return new OrderDto
        {
            Id = newOrder.Id,
            Amount = newOrder.Amount,
            CreatedTime = newOrder.CreatedTime
        };
    }
}

注意事项 #

如果需要跨多个服务操作保证数据一致性，可以直接在上层调用方通过_context.Database.BeginTransactionAsync()开启事务，统一控制提交或回滚，无需额外封装自定义工作单元类。
这种架构的优势是可以完全复用EF Core的原生特性，包括投影查询、跟踪配置、全局查询筛选、关联数据加载（Include）等能力，不需要在仓储层封装大量重复的增删改查模板代码，开发和维护效率都更高。

内容的提问来源于stack exchange，提问作者Guillermo Verón