entity-framework - EF4 和 MVC3 - 我需要存储库模式吗？

Question

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

当我将它们添加到项目中时，我想知道果汁是否值得众所周知的挤压，鉴于以下情况:

底层数据访问机制极不可能从 EF4 更改。

这种抽象级别将需要更多的开销/混淆项目和团队中的其他开发人员。

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

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

Answer 1

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

这将使一些更复杂的 EF 相关任务更难实现，或者您的存储库和 UoW 实现将需要具有与 EF 的

非常相似的公共(public)接口(interface)

它不会使您的代码更好地进行单元测试，因为与存储库的所有交互仍必须包含在集成测试中。不仅我的经验证明，通过将 linq-to-entities 替换为 linq-to-objects 来模拟 EF 代码并不能测试您的代码。