如何模拟实体框架的导航属性智能？

Question

我正在尝试使用内存中的模拟上下文来测试我的存储库。

我用内存字典来实现这一点，就像大多数人一样。这实现了存储库接口上的成员，以添加、删除、查找等，处理内存中的集合。

这在大多数情况下都很好：

[TestMethod]
public void CanAddPost()
{
    IRepository<Post> repo = new MockRepository<Post>();
    repo.Add(new Post { Title = "foo" });
    var postJustAdded = repo.Find(t => t.Title == "foo").SingleOrDefault();
    Assert.IsNotNull(postJustAdded); // passes
}

但是，我有下面的测试，我无法通过模拟存储库(对于SQL存储库很好)。

假设我有三个存储库：

1. Posts (处理用户内容发布，如StackOverflow question).
2. Locations (在世界上的位置，如"Los Angeles").
3. LocationPosts“)(用于处理多个Posts/Locations).

之间的连接表)。

文章可以添加到任何地方，也可以添加到特定的位置。

现在，我的测试是：

[TestMethod]
public void CanAddPostToLocation()
{
   var location = locationRepository.FindSingle(1); // Get LA
   var post = new Post { Title = "foo", Location = location }; // Create post, with LA as Location.
   postRepository.Add(post); // Add Post to repository

   var allPostsForLocation = locationPostRepository.FindAll(1); // Get all LA posts.
   Assert.IsTrue(allPostsForLocation.Contains(post)); // works for EF, fails for Mock.
}

基本上，当使用“真正”EF/SQL时，当我将Post添加到特定位置时，EntityFramework足够聪明地添加"LocationPost“记录，因为在EDMX ( "Post”实体上的“LocationPosts”导航属性)中存在关联。

但是，我如何使我的模拟库足够聪明，“模仿”这个EF智能呢？

当我在模拟存储库中“添加”时，这只会添加到字典中。“哦，等等，你有一个依赖的关联，让我为你把它添加到另一个存储库中”，这是不明智的。

我的模拟库是通用的，所以我不知道如何把智能放在里面。

我也考虑过创建一个FakeObjectContext / FakeObjectSet (正如Julie在她的博客中所建议的那样)，但这仍然没有涉及到这个场景。

我觉得我的嘲笑方案还不够好。有人能帮上忙，或者提供一篇关于如何正确模拟实体框架4/ Server存储库的最新文章，涵盖我的场景吗？

问题的核心是，每个聚合根有一个存储库(这很好，但也是我的失败)。

因此，LocationPosts.的Post和Location都是聚合根，但两者都不是“拥有”的

因此，它们是3个独立的存储库，而在内存中的场景中，它们是3个独立的字典。我想我错过了记忆中它们之间的“胶水”。

编辑

部分问题是，我正在使用Pure的(没有EF代码生成)。我也没有任何更改跟踪(没有基于快照的跟踪，没有代理类)。

我的印象是，这就是“聪明”发生的地方。

目前，我正在探索一种代表的选择。我在我的Generic存储库中公开了一个事件(void，接受泛型T，作为实体)，在"Add“之后调用该事件。然后，我在我的"Post“中订阅这个事件，在那里我计划将相关实体添加到其他存储库中。

这应该能行。如果它这样做了，就会把它作为答案。

然而，我不确定这是最好的解决方案，但同样，这只是满足模拟(代码不会用于真正的功能)。

Answer 1

正如我在编辑中所说的，我探索了委托选项，它成功地发挥了作用。

我就是这样做的：

namespace xxxx.Common.Repositories.InMemory // note how this is an 'in-memory' repo
{
   public class GenericRepository<T> : IDisposable, IRepository<T> where T : class
   {
      public delegate void UpdateComplexAssociationsHandler<T>(T entity);
      public event UpdateComplexAssociationsHandler<T> UpdateComplexAssociations;

      // ... snip heaps of code

      public void Add(T entity) // method defined in IRepository<T> interface
      {
         InMemoryPersistence<T>().Add(entity); // basically a List<T>
         OnAdd(entity); // fire event
      }

      public void OnAdd(T entity)
      {
         if (UpdateComplexAssociations != null) // if there are any subscribers...
            UpdateComplexAssociations(entity); // call the event, passing through T
      }
   }
}

然后，在我的内存中，“”(从上面的类继承)。

public class PostRepository : GenericRepository<Post>
{
   public PostRepository(IUnitOfWork uow) : base(uow)
   {
      UpdateComplexAssociations += 
                  new UpdateComplexAssociationsHandler<Post>(UpdateLocationPostRepository);
   }

   public UpdateLocationPostRepository(Post post)
   {
      // do some stuff to interrogate the post, then add to LocationPost.
   }
}

您可能还会想：“等等，PostRepository是从GenericRepository派生的，那么为什么要使用委托，为什么不重写添加呢？”答案是"Add“方法是IRepository的接口实现，因此不能是虚拟的。

正如我所说的，这不是最好的解决方案--但这是一个嘲讽的场景(对于代表来说也是一个很好的例子)。我的印象是，没有多少人在嘲笑、纯粹的POCO和存储库/工作单元模式(在POCO上没有变化跟踪)方面“走到了这么远”。

希望这能帮到别人。