为什么没有IDbContext实体框架接口？ 那岂不是更容易，如果有喜欢用的SaveChanges（）方法等，从中你可以派生自定义数据库上下文接口现有接口进行测试的东西呢？
public interface ICustomDbContext : IDbContext
{
// add entity set properties to existing set of methods in IDbContext
IDbSet<SomeEntity> SomeEntities { get; }
}
我看到这个IDbContext ：
看到此链接 ，然后你做一个新的部分类的实体语境与该接口。
public partial class YourModelEntities : DbContext, IDbContext
编辑：我编辑这个职位，这对我的作品。 我的上下文
namespace dao
{
public interface ContextI : IDisposable
{
DbSet<TEntity> Set<TEntity>() where TEntity : class;
DbSet Set(Type entityType);
int SaveChanges();
IEnumerable<DbEntityValidationResult> GetValidationErrors();
DbEntityEntry<TEntity> Entry<TEntity>(TEntity entity) where TEntity:class;
DbEntityEntry Entry(object entity);
string ConnectionString { get; set; }
bool AutoDetectChangedEnabled { get; set; }
void ExecuteSqlCommand(string p, params object[] o);
void ExecuteSqlCommand(string p);
}
}
YourModelEntities是你自动生成的部分类，和你需要创建一个新的部分类具有相同的名称，然后添加新的上下文接口，在这个例子是上下文1
注：该接口并没有实现所有的方法，因为这些方法是在你的自动生成的代码来实现。
namespace dao
{
public partial class YourModelEntities :DbContext, ContextI
{
public string ConnectionString
{
get
{
return this.Database.Connection.ConnectionString;
}
set
{
this.Database.Connection.ConnectionString = value;
}
}
bool AutoDetectChangedEnabled
{
get
{
return true;
}
set
{
throw new NotImplementedException();
}
}
public void ExecuteSqlCommand(string p,params object[] os)
{
this.Database.ExecuteSqlCommand(p, os);
}
public void ExecuteSqlCommand(string p)
{
this.Database.ExecuteSqlCommand(p);
}
bool ContextI.AutoDetectChangedEnabled
{
get
{
return this.Configuration.AutoDetectChangesEnabled;
}
set
{
this.Configuration.AutoDetectChangesEnabled = value;
}
}
}
}
我也想过这个问题，我想你会用它来嘲弄 DbContext 。 我觉得没有理由认为，除了你将需要实现自己的DbSet手动在你反正你嘲笑类（所以需要无论如何重写自己的界面）。
只要创建扩展您的生产的DbContext从而覆盖复杂的测试方法的模拟的DbContext。 这样一来，生产的DbContext任何更改会自动反映在测试中，保存为覆盖的方法。 对于应对持久性和乘坐的DbContext只是延长他们以及通过在扩展模拟的DbContext任何其他类。
namespace Test.Mocks
{
public sealed class MockDatabaseContext : MainProject.Persistence.Database.DatabaseContext
{
public MockDatabaseContext(ConfigurationWrapper config) : base(config)
{
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
var dbPath = "test.db";
optionsBuilder.UseSqlite($"Filename={dbPath}");
}
}
}
namespace Test.Mocks
{
public class MockInventoryFacade : InventoryFacade
{
public MockInventoryFacade(MockDatabaseContext databaseContext) : base(databaseContext)
{
}
}
}
没有IDbContext因为这将是无用的，它的唯一的实施将是的DbContext。
EF团队也将这种方式与IDbSet如果你看看这个设计补注
对我来说，与EF真正的问题，当涉及到单元测试是的DbConnection中的DbContext，好在有劲道启动填补这个CodePlex上的一个很好的项目。
力量是强大的工具，使一个方便的方法来创建基于实体框架的应用自动化测试。 它基本上是一个ADO.NET提供者执行一个轻量级进程内存数据库，而不是传统的外部数据库中的所有数据操作。 它提供了一些直观的辅助方法，也使很容易使用这个供应商与现有的ObjectContext或类别的DbContext。 一个简单的除现有的代码可能足以创建一个可以在没有外部数据库存在运行数据驱动测试。
有了这个，你可以留下你的DbContext和DbSet的是，容易做单元测试。 这个唯一的缺点是LINQ提供其中一些单元测试可以通过努力而不是与真正的后端之间的差异。
更新与EF7
我仍然认为IDbContext将是无用的，问题来自于的DbConnection。
EF7不会有IDbContext无论是为了做单元测试，他们现在在内存供应商发出的。
你可以看到罗恩·米勒做了演示在这里： 与实体框架7现代数据应用
