c# – EF6 DbContext IOC依赖关系

using(var db = new MyContext())
{
// code reading from/writing to database
...
...
}

要解决分离(和测试)问题,您可以为DbContext(IMyDbContext)创建自己的接口,并重新公开所有类型化的实体DbSets,SaveChanges()以及可能的其他一些方法.您还应该使此接口为Disposable.

public interface IMyDbContext : IDisposable
{
    IDbSet<Foo> Foos { get; set; }
    IDbSet<Bar> Bars { get; set; }

    int SaveChanges();
    DbEntityEntry<T> Entry<T>(T entity) where T : class;
}

(您也可以考虑接口的只读和读写版本)

然后更改具体的DbContext以实现此接口.您现在可以合理地与DbContext(用于单元测试等)分离,但仍然可以访问IQueryable的有用性,固有工作单元和DbContext提供的缓存.

然后,这里有两个选项,用于将IMyDbContext注入到您的业务/服务类中

>构造函数注入IDbContext

要么

>创建一个Factory方法和一个Factory接口,用于创建具体的DbContexts,然后对IMyDbContextFactory工厂接口进行构造函数注入(您将需要接口,而不是具体工厂,再次用于模拟测试目的).

这里的选择取决于您需要对DbContext执行的操作.在IoC容器中配置#1可能很棘手,因为您需要将生命周期管理移交给容器.但是,如果可以为每个请求配置新实例,那么这在Web应用程序中可能是有益的,因此如果请求(假设单个线程)可以将其用作缓存.

我个人更喜欢#2,因为这允许直接管理上下文：

using(var db = _myContextFactory.CreateDB())
{
    db.SaveChanges();
}

但显然,我们失去了长期环境(如缓存)的任何潜在好处.但是,如果需要,还有许多其他替代技术可用于缓存.

需要注意的是：DbContext根本不是线程安全的 – 如果您使用的是TPL,请确保每个任务都获得自己的DbContext实例 – 例如使用Parallel.For / ForEach的localinit重载在使用它时实例化它.