Jim*_*Jim 2 c# repository-pattern nerddinner asp.net-mvc-4 entity-framework-5
我一直在查看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已经是工作单元和存储库的抽象,数据上下文是工作单元,dbsets是存储库.他们声称LINQ是查询语言的足够抽象,并且您不需要特定的受限API.
其他人说,假设所有可能的提供者在相同的LINQ查询中提供一致结果的意义上是兼容的,这是不安全的.某些提供商可能会受到限制甚至拒绝评估特定查询.这个 - 人们说 - 意味着您仍然需要对 EF 进行抽象,以便保证更高层的相同数据协定.
如果有人决定从示例中删除存储库层,这可能是由于以下两个原因之一:
就个人而言,我喜欢存储库并尽可能使用它们.
| 归档时间： |
|
| 查看次数： |
1755 次 |
| 最近记录： |