是否应该通过 DI 使用实体框架 DbContext 的存储库实现 IDisposable？答案

【问题标题】：Should repositories using Entity Framework DbContext via DI implement IDisposable?是否应该通过 DI 使用实体框架 DbContext 的存储库实现 IDisposable？
【发布时间】：2015-07-20 12:39:27
【问题描述】：

我已经看到了 EF7 人员在构造函数中注入数据上下文的示例。

但是，由于 DbContext 实现了 IDisposable，我担心我的存储库也必须实现 IDisposable，通过代码进行传播。

我看到的例子没有实现 IDisposable，但我不知道为什么。

编辑

澄清以前我以通常的方式使用数据库上下文

using(var db = new SomeContext())
{
    return await from row in db.Table
        select row).ToListAsync();
}

查看 DbContext 将被传递到存储库构造函数的注入方式，但是一旦存储库完成，此存储库是否必须实现 IDisposable 来处置 DbContext？

如果存储库随后调用另一个存储库类来更改其注入的 DbContext，则此 DBContext 是否存在风险？

即

public SomeOtherRepository (SomeContext db)
{
    this.db = db;
}

public SomeRepository (SomeOtherRepository repo, SomeContext db)
{
    this.repo = repo;
    this.db = db;
}
public async TaskAdd(Row row)
{
    db.Some.Add(row);
    await db.SaveChangesAsync();
    repo.AddSomethingElse(row.Id);
}

【问题讨论】：

我认为 DI 处理对象的生命周期由 DI 容器本身处理。在某些情况下，一个单例对象根本不会被释放

标签： entity-framework-core

【解决方案1】：

您不需要重写 DbContext.Dispose。

除非您需要释放在自定义 DbContext 中创建的资源，否则框架提供的基本实现就足够了。

【讨论】：

很抱歉在最初的问题中没有让自己说清楚，并对此进行了扩展。我的问题不在我的 DbContext 上，而是在其构造函数中使用它的类
这取决于你如何配置 DI，正如@luca 之前提到的。重用同一个 DbContext 实例的危险在于 context.SaveChanges() 可能会产生意想不到的后果。