NerdDinner MVC4版本 – 为什么他们删除了存储库类？
我一直在查看NerdDinner教程。 我正在阅读使用LINQ to SQL和MVC2的原始PDF教程（ http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf ）。 在该教程中，他们实现数据上下文，然后实现存储库类以与数据实体交互。
我看到项目已更新为使用MVC4和entity framework（ http://nerddinner.codeplex.com ），因此我浏览了该代码以查看它们实现了哪些更改。 他们将项目更改为代码优先，每个数据实体都有单独的模型类。 我惊讶地发现他们完全摆脱了存储库。
我认为通过存储库模式抽象与数据库的通信通常是一种很好的做法…我知道教程通常会为了简洁而做出糟糕的设计选择，但我想知道为什么已经实现了存储库的教程做出了决定从这个版本中省略它们。
MVC4或EF中是否存在使存储库过时/冗余的问题？
关于在存储库中包含诸如entity framework之类的高级抽象是否有意义存在长期争论。
从历史上看，存储库很棒。 为了能够在不同的数据提供者，普通的旧数据集，文件，linq等之间切换，有一个额外的抽象层是安全的。
但是，许多EF纯粹主义者声称EF已经是工作单元和存储库的抽象，数据上下文是工作单元，dbsets是存储库。 他们声称LINQ是查询语言的足够好的抽象，并且您不需要特定的受限API。
其他人说，假设所有可能的提供者在相同的LINQ查询中提供一致结果的意义上是兼容的，这是不安全的。 有些提供商可能会受到限制甚至拒绝评估特定查询。 这个 – 人们说 – 意味着你仍然需要对 EF进行抽象，以便保证更高层的相同数据合同。
如果有人决定从示例中删除存储库层，这可能是由于以下两个原因之一：
- 有人意识到存储库只是使示例更复杂，并为简单起见删除它们
- 作为EF纯粹主义者的人想提倡“没有任何东西可以站在EF之上”的事实
就个人而言，我喜欢存储库并尽可能使用它们。
随着CQRS普及程度的提高 ，Repository模式有点不受欢迎 ，像Jimmy Bogard这样的人在使用它时遇到了好的案例 。
基本上，存储库很容易最终成为一个知道如何形成大量不同查询的大型类，违反了SRP 。 在复杂的系统中避免这种情况最终会为您提供大量的存储库，而在简单的系统中使用存储库只是过度工程化。