实现存储库模式并进行测试答案

【问题标题】：Implementing Repository pattern and doing Tests实现存储库模式并进行测试
【发布时间】：2012-09-02 12:22:35
【问题描述】：

我已经阅读了几乎所有关于存储库模式及其不同实现的文章。他们中的许多人认为不好的做法（例如：使用IQueryable<T> 而不是IList<T>）等等，这就是为什么我仍然被卡住并且无法最终找到正确的做法。

所以：

我是否需要存储库模式才能在我的 MVVM 应用程序中应用 IoC？
如果是，什么是 EF 实体的有效 IRepository 实现，这是一种良好的实践和更好的可测试性？
如何测试我的存储库和 UnitofWork 行为？针对内存存储库的单元测试？集成测试？

编辑：根据答案我添加了第一个问题。

【问题讨论】：

标签： entity-framework unit-testing integration-testing repository-pattern

【解决方案1】：

Ayende Rahien 有很多关于存储库 http://ayende.com/blog/search?q=repository 的帖子，以及为什么使用 ORM 时它不好。我认为存储库是要走的路。也许是，在 2004 年。不是现在。 ORM 已经实现了存储库。在 EF 的情况下，它是 IDbSet。而 DbContext 是 UnitOfWork。创建一个存储库来包装 EF 或其他 ORM 会增加很多不必要的复杂性。

对将与数据库交互的代码进行集成测试。

【讨论】：

感谢您的回复。我已经提到我看过几乎所有的帖子，包括 Ayende 的帖子。我的问题在效率上非常精确（带参数）。
没问题。我不知道你读过它。他说没有好的存储库。 IList 代替 IQueryable 变化不大。所以我以为你没有读过他的博客。您要求存储库实施是一种很好的做法。所以答案是没有。不使用 ORM。

【解决方案2】：

当您使用 EF 时，存储库模式添加了一个额外的层，因此您应该确保您需要这个额外的间接级别。

存储库模式的最初想法是保护上面的层免受数据库结构的复杂性和了解。在许多方面，EF 的 ORM 模型保护代码免受数据库中物理实现的影响，因此对存储库的需求更少。

有两种基本的选择：

让业务层直接与 EF 模型对话
构建一个实现 Repository 模式的数据层，该层将 EF 对象映射到 POCO

对于测试：

当我们直接使用 EF 时，我们使用带有回滚功能的事务范围，因此测试不会更改数据。
当我们使用存储库模式时，我们使用 Rhino Mocks 来模拟存储库

我们使用这两种方法，存储库模式提供了更清晰的分层应用程序，因此可能有更多的控制权，直接使用 EF 可以提供更少代码的应用程序，因此构建速度更快。

【讨论】：

测试呢？我的意思是如何在不使用存储库模式的情况下进行测试？
感谢您的回复，但您没有回答我的第一个问题。
我还是 EF 新手，但是如果您使用 TransactionScope，您如何测试是否可以写入数据库？我认为您不能使用相同的 DbContext (DataContext) 进行读写。并且当您打开事务（未提交）时，第二个上下文将无法读取第一个写入的数据。