应该使用实体框架DbContext通过DI实现IDisposable？

我已经看到了在构造函数中注入datacontext的EF7人员的例子。应该使用实体框架DbContext通过DI实现IDisposable？

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

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

编辑

为了澄清以前我是用分贝范围内以通常的方式

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

看做事的注射方式的DbContext将被传递到存储库构造函数，但是一旦Repository完成，这个存储库是否必须实现IDisposable来处置DbContext？

如果Repository随后会调用另一个更改其注入的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); 
}

来源

2015-05-09 Peter M

我想DI处理对象的生命周期是由DI容器本身处理的。在某些情况下，单件对象根本不配置 –

您不需要重写DbContext.Dispose。

除非您需要取消分配在您的DbContext自定义中创建的资源，否则框架提供的基本实现应该已足够。

来源

2015-05-20 16:47:46 natemcmaster

对不起，在最初的问题中没有明确说明，并且已经扩展了它。我的问题不在我的DbContext上，而是在构造函数 –

中使用它的类取决于你如何配置DI，如前面提到的@luca。重用DbContext实例的危险在于context.SaveChanges（）可能会产生意想不到的后果。 – natemcmaster

应该使用实体框架DbContext通过DI实现IDisposable？

回答

相关问题