c# - 如何模拟 Entity Framework 导航属性智能？

Question

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

像大多数人一样，我使用内存中的字典来实现它。这实现了我的存储库接口(interface)上的成员，以使用内存中的集合进行添加、删除、查找等操作。

这在大多数情况下都能正常工作:

[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. 帖子(处理用户内容帖子，例如 StackOverflow 问题)。
2. 位置(世界上的位置，例如“洛杉矶”)。
3. LocationPosts(用于处理帖子/位置之间的多对多连接表)。

帖子可以添加到任何地方，也可以添加到特定位置。

现在，这是我的测试:

[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 存储库时，当我将帖子添加到特定位置时，EntityFramework 足够智能以添加“LocationPost”记录，因为 EDMX 中的关联(“LocationPosts”导航“Post”实体的属性)

但是我怎样才能使我的 Mock 存储库足够智能以“模仿”这个 EF 智能？

当我在我的模拟存储库上执行“添加”时，这只会添加到字典中。它没有智慧去“哦，等等，你有一个依赖关联，让我为你把它添加到 OTHER 存储库”。

我的 Mock Repository 是通用的，所以我不知道如何把智能放在那里。

我也研究过创建 FakeObjectContext/FakeObjectSet(正如 Julie Lerman 在她的博客上所建议的那样)，但这仍然没有涵盖这种情况。

我觉得我的模拟解决方案不够好。任何人都可以帮助或提供有关如何正确模拟涵盖我的场景的 Entity Framework 4/SQL Server 存储库的最新文章吗？

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

所以 Post 和 Location 都是聚合根，但都不“拥有”LocationPosts。

因此它们是 3 个独立的存储库，在内存场景中，它们是 3 个独立的字典。我认为我在内存存储库中缺少它们之间的“胶水”。

编辑

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

我的印象是这就是“智慧”发生的地方。

目前，我正在探索委托(delegate)选项。我在我的通用模拟存储库(无效，接受通用 T，作为实体)中公开一个事件，我在“添加”之后调用它。然后我在我的“Post Repository”中订阅了这个事件，我计划在其中将相关实体添加到其他存储库。

这应该有效。如果这样做，将作为答案。

但是，我不确定这是最好的解决方案，但话又说回来，这只是为了满足模拟(代码不会用于实际功能)。

Answer 1

正如我在 EDIT 中所说，我探索了委托(delegate)选项，该选项已成功运行。

这是我的做法:

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
      }
   }
}

然后，在我的 In Memory “Post Repository”(继承自上述类)中。

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，那么为什么要使用委托(delegate)，为什么不覆盖 Add？”答案是“添加”方法是 IRepository 的接口(interface)实现 - 因此不能是虚拟的。

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

希望这对其他人有帮助。