2

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

所以：

  • 我是否需要存储库模式才能在我的 MVVM 应用程序中应用 IoC？

  • 如果是，什么是 EF 实体的有效 IRepository 实现，这是一种良好的实践和更好的可测试性？

  • 如何测试我的存储库和 UnitofWork 行为？针对内存存储库的单元测试？集成测试？

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

4

2 回答 2

3

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

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

于 2012-09-09T11:32:10.057 回答
1

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

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

有 2 个基本的替代方案：

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

对于测试：

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

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

于 2012-09-09T11:09:44.130 回答