实体框架 – 带MVC3的EF4 – 我需要存储库模式吗？

发布时间：2020-12-15 21:02:37 所属栏目：asp.Net 来源：网络整理

导读：我最近了解了存储库和工作单元设计模式,并认为我将在新的EF4 MVC3项目中实现它们,因为抽象通常很好. 当我将它们添加到项目中时,我想知道果汁是否值得谚语挤压,给出以下内容：基础数据访问机制极不可能从EF4发生变化. 这种抽象级别将需要更多的开销/混淆项目

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

当我将它们添加到项目中时,我想知道果汁是否值得谚语挤压,给出以下内容：

>基础数据访问机制极不可能从EF4发生变化.
>这种抽象级别将需要更多的开销/混淆项目和团队中的其他开发人员.

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

我是否应该费心实施这种抽象？我觉得必须有一些我遗漏的巨大好处,但我觉得我不需要沿着这条路走下去.我愿意相信;有人可以提起诉讼吗？谢谢.

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

>它将使更复杂的EF相关任务更难实现,或者您的存储库和UoW实现需要具有与EF相似的公共接口>它不会使您的代码更好地进行单元测试,因为与存储库的所有交互仍必须由集成测试覆盖.不仅我的经验证明,通过用linq-to-objects替换linq-to-entities来模拟EF代码不会测试你的代码.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!