存储库模式与entity framework4.1和父/子关系
我仍然对仓库模式有一些困惑。 我想要使用这种模式的主要原因是为了避免从域中调用EF 4.1特定的数据访问操作。 我宁愿从IRepository接口调用通用的CRUD操作。 这将使testing更容易，如果将来我必须更改数据访问框架，我将能够在不重构大量代码的情况下进行testing。
这是我的情况的一个例子：
我在数据库中有3个表： Group ， Person和GroupPersonMap 。 GroupPersonMap是一个链接表，只包含Group和Person主键。 我使用VS 2010devise器创build了3个表格的EF模型。 EF足够聪明地假设GroupPersonMap是一个链接表，所以它不会在devise器中显示它。 我想使用现有的域对象而不是EF生成的类，所以我closures了模型的代码生成。
我现有的类与EF模型匹配如下：
public class Group { public int GroupId { get; set; } public string Name { get; set; } public virtual ICollection<Person> People { get; set; } } public class Person { public int PersonId {get; set; } public string FirstName { get; set; } public virtual ICollection<Group> Groups { get; set; } }
我有一个通用的存储库接口，如下所示：
public interface IRepository<T> where T: class { IQueryable<T> GetAll(); T Add(T entity); T Update(T entity); void Delete(T entity); void Save() }
和一个通用的EF仓库：
public class EF4Repository<T> : IRepository<T> where T: class { public DbContext Context { get; private set; } private DbSet<T> _dbSet; public EF4Repository(string connectionString) { Context = new DbContext(connectionString); _dbSet = Context.Set<T>(); } public EF4Repository(DbContext context) { Context = context; _dbSet = Context.Set<T>(); } public IQueryable<T> GetAll() { // code } public T Insert(T entity) { // code } public T Update(T entity) { Context.Entry(entity).State = System.Data.EntityState.Modified; Context.SaveChanges(); } public void Delete(T entity) { // code } public void Save() { // code } }
现在假设我只想将现有的Group映射到现有的Person 。 我将不得不做如下的事情：
EFRepository<Group> groupRepository = new EFRepository<Group>("name=connString"); EFRepository<Person> personRepository = new EFRepository<Person>("name=connString"); var group = groupRepository.GetAll().Where(g => g.GroupId == 5).First(); var person = personRepository.GetAll().Where(p => p.PersonId == 2).First(); group.People.Add(person); groupRepository.Update(group);
但是这不起作用，因为EF认为Person是新的，并且会尝试将Person重新INSERT数据库，这将导致主键约束错误。 我必须使用DbSet的Attach方法来告诉EF这个Person已经存在于数据库中，所以只需在GroupPersonMap表中的Group和Person之间创build一个映射。
所以为了将Person附加到上下文中，我现在必须在我的IRepository中添加一个Attach方法：
public interface IRepository<T> where T: class { // existing methods T Attach(T entity); }
修复主键约束错误：
EFRepository<Group> groupRepository = new EFRepository<Group>("name=connString"); EFRepository<Person> personRepository = new EFRepository<Person>(groupRepository.Context); var group = groupRepository.GetAll().Where(g => g.GroupId == 5).First(); var person = personRepository.GetAll().Where(p => p.PersonId == 2).First(); personRepository.Attach(person); group.People.Add(person); groupRepository.Update(group);
固定。 现在我必须处理另一个问题，每次创build组/人员映射时，数据库中的Group都将被更新。 这是因为在我的EFRepository.Update()方法中，实体状态显式设置为“ Modified'. I must set the Group's state to Modified'. I must set the Group's state to更改”， so the组”表不被修改。
为了解决这个问题，我们必须在我的IRepository中添加一些Update重载，在这种情况下，它不更新根实体或者Group ：
public interface IRepository<T> where T: class { // existing methods T Update(T entity, bool updateRootEntity); }
Update方法的EF4实现看起来像这样：
T Update(T entity, bool updateRootEntity) { if (updateRootEntity) Context.Entry(entity).State = System.Data.EntityState.Modified; else Context.Entry(entity).State = System.Data.EntityState.Unchanged; Context.SaveChanges(); }
我的问题是：我以正确的方式接近这个吗？ 当我开始使用EF和存储库模式时，我的存储库开始看起来以EF为中心。 感谢您阅读这篇长文章
我想要使用这种模式的主要原因是为了避免从域中调用EF 4.1特定的数据访问操作。 我宁愿从IRepository接口调用通用的CRUD操作。 这将使testing更容易
不，它不会让你的testing更容易 。 您公开了IQueryable因此您的存储库不是单元可testing的 。
如果将来我不得不改变数据访问框架，我将能够在不重构大量代码的情况下这样做。
不，你不得不改变很多代码，因为你暴露了IQueryable而且因为EF / ORM是漏洞抽象的 – 你的上层希望在你的ORM中发生一些神奇的行为（例如延迟加载）。 这也是存储库最奇怪的原因之一。 现在只需select正确的技术，并使用它来获得它的赌注。 如果你以后不得不改变它，那么意味着你要么做错了，要么选错了 ，要么改变了要求 – 无论是哪种情况，都是很多的工作。
但是这不起作用，因为EF认为Person是新的，并且会尝试将Person重新插入数据库，这将导致主键约束错误。
是的，因为你正在为每个存储库使用一个新的上下文=这是错误的方法。 存储库必须共享上下文。 您的第二个解决scheme也不正确，因为您将EF依赖关系放回应用程序 – 存储库正在公开上下文。 这通常是通过第二种模式 – 工作单元来解决的。 工作单元包装上下文 ，工作单元形成primefaces更改集 – SaveChanges必须暴露在工作单元上，以提交所有相关存储库完成的更改。
现在我每次想要创build一个Group / Person映射时，都会在数据库中更新Group。
你为什么改变状态？ 您从存储库中接收到实体，因此直到您分离它为止，没有理由调用Attach并手动更改状态。 这一切都应该在附属实体上自动发生。 只需调用SaveChanges 。 如果你正在使用分离的实体，那么你必须正确地为每个实体和关系设置状态，所以在这种情况下，你确实需要一些逻辑或更新重载来处理所有场景。
我以正确的方式接近这个吗？ 当我开始使用EF和存储库模式时，我的存储库开始看起来以EF为中心。
我不这么认为。 首先你不使用聚合根。 如果你这样做，你会立即发现， 通用的存储库是不适合的。 聚合根的存储库为每个聚合根具有特定的方法来处理由根聚合的关系。 Group不是Person聚合的一部分，但GroupPersonMap应该是这样的，您的Person存储库应该有特定的方法来处理从人员添加和删除组（而不是自己创build或删除组）。 Imo通用存储库是冗余层 。
