我一直在检查NerdDinner教程。我正在阅读使用LINQ to SQL和MVC2的原始PDF教程(http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf)。在该教程中,他们实现了数据上下文,然后实现了存储库类以与数据实体进行交互。
我看到该项目已更新为使用MVC4和Entity Framework(http://nerddinner.codeplex.com),所以我浏览了该代码以查看它们实现了哪些更改。他们将项目更改为代码优先,并为每个数据实体使用了单独的模型类。令我惊讶的是,他们完全摆脱了存储库。
我认为通过存储库模式与数据库进行抽象通信通常是一种好习惯……我知道,为了简洁起见,教程经常会做出糟糕的设计选择,但是我想知道为什么已经实施了存储库的教程才能做出决定从此版本中忽略它们。
MVC4或EF中是否有某些东西会使存储库过时/多余?
关于将诸如实体框架之类的高级抽象包装在存储库中是否有意义,存在着长期的争论。
从历史上看,存储库很棒。为了能够在不同的数据提供程序,普通旧DataSet
文件,文件,linq等之间切换,有一个额外的抽象层是安全的。
但是,许多EF纯粹主义者声称EF已经是工作单元和存储库的抽象,其中数据上下文是工作单元,而dbset是存储库。他们声称LINQ是查询语言的足够好的抽象,并且您不需要特定的受限API。
其他人则说,假设所有可能的提供程序都为同一LINQ查询提供一致的结果是兼容的,这是不安全的。某些提供程序可能会受到限制,甚至拒绝评估特定查询。有人说,这意味着您仍然需要基于EF的抽象,以便为更高的层保证相同的数据协定。
如果有人决定从示例中删除存储库层,则可能是由于以下两个原因之一:
就个人而言,我喜欢存储库,并尽可能使用它们。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句