服务层使用DbContext：注入实例还是方法内using创建？能否并行查询？

我在某测试项目中采用分层架构：Web API <-> Service（包含DbContext）。我没有使用仓储模式，因为DbSet本身已经具备仓储的功能。

我的Service类定义如下：

public class MyService : DbContext
{
    public MyService(DbContextOptions<MyDbContext> options)
        : base(options)
    {
    }
    ...
}

现在我有两个疑问：

1. 应该为每个Service注入DbContext，还是在每个方法内部通过using语句创建DbContext？
   方法内创建DbContext的示例代码：

DoSomething()
{
   using (var db = new DbContext())
   {
      ...
   }
}

2. 方法内创建DbContext的优势在于可以并行执行不同查询（我当前存在此类场景，目前三个查询是串行执行的）。另外，我是否可以同时结合这两种方式？

两种方式的核心区别 #

注入DbContext的方式 #

• 生命周期省心可控：在ASP.NET Core中，DbContext默认是Scoped生命周期，和请求周期绑定，同一个请求内的所有服务共享同一个DbContext实例，天然支持事务一致性，适合需要跨方法共享实体跟踪状态（比如修改实体后在其他方法保存）的场景。
• 测试维护更便捷：符合依赖注入设计原则，单元测试时可轻松Mock DbContext，代码耦合度更低。
• 硬限制：同一个DbContext实例不支持并行执行查询，EF Core会抛出线程安全异常，这也是你当前查询只能串行的原因。

方法内用using创建DbContext的方式 #

• 完美适配并行查询：每个方法内的DbContext都是独立实例，互不干扰，刚好解决你需要并行执行多个查询的需求。
• 资源自动清理：using语句会自动释放DbContext及底层数据库连接，避免资源泄漏。
• 短板：无法跨方法共享实体跟踪状态，若需在多个方法间保持实体修改状态，这种方式会很繁琐；另外每次创建实例存在少量性能开销，但绝大多数场景下可忽略不计。

是否可以结合两种方式？ #

完全可以，根据场景灵活选择：

• 当需要事务一致性、实体变更跟踪，或同一个请求内多个方法需共享上下文时，使用注入的Scoped DbContext。
• 当需要并行执行多个独立查询且无需共享上下文状态时，在方法内通过using创建独立的DbContext实例。

注意：混用两种方式时，需明确各自适用场景，避免在同一业务流程中同时用两种上下文操作同一实体，防止出现状态不一致的问题。

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