我總是創建通過我自己的接口的背景下DataContextFactory,並通過了我的資料庫,像這樣:
上下文接口:
public IMyDataContext {
// One per table in the database
IDbSet<Class1> Class1s { get;set; }
// etc
// The standard methods from EF you'll use
void Add(object Entity);
void Attach(object Entity);
void Delete(object Entity);
void SaveChanges();
}
上下文工廠:
public class MyDataContextFactory : IMyDataContextFactory {
public IMyDataContext GetContext() {
// TODO: Use the service locator pattern to avoid the direct instanciation
return new MyDataContext();
}
}
上下文工廠接口:
public interface IMyDataContextFactory {
IMyDataContext GetContext();
}
存儲庫:
public class MyClass1Repository {
private readonly IMyDataContextFactory factory;
public MyClass1Repository(IMyDataContextFactory Factory) {
// TODO: check for null
this.factory = Factory;
}
public List<MyClass1> GetAll() {
using (IMyDataContext db = this.factory.GetContext()) {
return db.Class1s.ToList();
}
}
// TODO: Other methods that get stuff
}
然後,當我想測試存儲庫中,我通過在假IMyDataContextFactory
返回從GetContext()
假IMyDataContext
。
隨着時間的推移,我注意到在庫重複,並且可以推動某些方法到基本信息庫:GetAll()
,Save()
,GetById()
有時候如果我有一致的主鍵等
這是否僅適用於EF POCO對象的工作?我正在使用EF EDMX模型。 – NullReference
使用DbContext(我的)和ObjectContext(你的)之間的唯一區別是IMyDataContext將具有像.AddObject()和.DeleteObject()而不是.Add()和.Remove()這樣的ObjectContext特定方法。 – robrich
一般的前提是Context是查詢不可知的,特定於數據存儲區的,Repository是一個強類型的包裝器,它將這個調用器/應用程序的其餘部分作爲特定於查詢的數據存儲不可知調用提供。他們傳遞參數,找回對象或列表。交換到一個新的數據存儲,你直接上下文,重命名倉庫的內部,應用程序的其餘部分保持不變。 – robrich