我最近了解了存储库和工作单元设计模式,并认为我将在新的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代码不会测试你的代码.
