EF4 和 MVC3 - 我需要存储库模式吗？答案

【问题标题】：EF4 with MVC3 - Do I need The Repository Pattern?EF4 和 MVC3 - 我需要存储库模式吗？
【发布时间】：2011-04-29 16:38:49
【问题描述】：

我最近了解了存储库和工作单元设计模式，并认为我会在一个新的 EF4 MVC3 项目中实现它们，因为抽象通常很好。

当我将它们添加到项目中时，我想知道果汁是否值得众所周知的挤压，考虑到以下几点：

底层数据访问机制极不可能从 EF4 更改。
这种抽象级别将需要更多的开销/混淆项目和团队中的其他开发人员。

我看到使用存储库模式的唯一真正好处是对应用程序进行单元测试。抽象出数据存储似乎没有用，因为我知道数据存储不会改变，而且，EF4 已经提供了一个非常好的抽象（我只是调用 .AddObject() ，看起来我正在修改内存集合，我只是调用 .SaveChanges() ，它已经提供了工作单元模式）。

我是否应该费心去实现这个抽象？我觉得我肯定错过了一些巨大的好处，但我觉得我不需要走这条路。我愿意被说服，否则；有人可以提出案子吗？谢谢。

【问题讨论】：

标签： entity-framework asp.net-mvc-3 repository-pattern unit-of-work

【解决方案1】：

我推荐你reading this answer and all linked questions。存储库是非常流行的模式，它确实使您的应用程序变得漂亮和干净。它让您觉得您的架构是正确的，但是关于使用 EF 的存储库模式的一些假设是不正确的。在我看来（在这些答案中描述）：

这将使一些更复杂的 EF 相关任务更难实现，或者您的存储库和 UoW 实现需要具有与 EF 非常相似的公共接口
它不会使您的代码更好地进行单元测试，因为与存储库的所有交互仍必须包含在集成测试中。不仅我的经验证明，通过将 linq-to-entities 替换为 linq-to-objects 来模拟 EF 代码并不能测试您的代码。

【讨论】：

如果您在 EF 中使用 POCO 对象，那么您应该可以更轻松地测试这些对象，并且可以将它们视为任何其他非 ef 对象。这大大简化了这种依赖关系。
@Adam：这不是关于 POCO，而是关于 linq-to-entities 提供商切换到 linq-to-objects，其中 L2E 只是 L2O 的子集。
你能给我一个关于这个问题的简单例子吗，我没有关注并想了解。

【解决方案2】：

yes yes yes :) - 首先 - 存储库模式有助于注入您的依赖项以进行单元测试。其次，它非常清楚地了解了哪些数据访问方法可用于获取某些东西，而不是人们杂项。直接针对 EF 层进行编码。尽管为 EF4 下载 POCO 模板，因此如果您碰巧将它们用作模型和/或不希望在您的 mvc 应用程序中引用任何 EF 依赖库引用，则您的类不会随身携带 EF 属性（假设您的存储库工作在）一个单独的项目（我推荐）。如果您使用所有视图模型，那么它不是那么重要，但它很好地使用“客户”对象而不需要额外的方法。在我看来它更干净。

【讨论】：