2

我一直在查看 NerdDinner 教程。我正在阅读原始 PDF 教程（使用 LINQ to SQL 和 MVC2的原始 PDF 教程 ( http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf )。在该教程中，他们实现了数据上下文，然后实现了存储库类以与数据实体进行交互。

我看到该项目已更新为使用 MVC4 和实体框架（http://nerddinner.codeplex.com )，因此我浏览了该代码以查看他们实施了哪些更改。他们将项目更改为代码优先，每个数据实体都有单独的模型类。我很惊讶地看到他们完全摆脱了存储库。

我认为通过存储库模式抽象与数据库的通信通常是一种好习惯......我知道为了简洁起见，教程通常会做出糟糕的设计选择，但我想知道为什么已经实现存储库的教程做出了决定从这个版本中省略它们。

MVC4 或 EF 中是否存在使存储库过时/冗余的东西？

4

2 回答 2

10

关于将实体框架等高级抽象包装在存储库中是否有意义存在长期争论。

从历史上看，存储库很棒。拥有一个额外的抽象层是安全的，只是为了能够在不同的数据提供者、普通DataSet的旧文件、文件、linq 等之间切换。

但是，许多 EF 纯粹主义者声称 EF 已经是工作单元和存储库的抽象，其中数据上下文是工作单元，数据库集是存储库。他们声称 LINQ 是查询语言的足够好的抽象，您不需要特定的、受限的 API。

其他人说，假设所有可能的提供程序都是兼容的，因为它们为相同的 LINQ 查询提供一致的结果，这是不安全的。一些提供商可能会受到限制，甚至拒绝评估特定查询。这 - 人们说 - 意味着您仍然需要对EF 进行抽象，以便您保证更高层的相同数据合同。

如果有人决定从示例中删除存储库层，这可能是由于以下两个原因之一：

  • 有人意识到存储库只会使示例更复杂，并为简单起见将其删除
  • 一个是 EF 纯粹主义者的人想要提倡“没有什么可以站在 EF 之上”这一事实

就个人而言，我喜欢存储库并尽可能使用它们。

于 2013-09-27T20:11:30.363 回答
4

随着CQRS的普及，存储库模式有点失宠，像 Jimmy Bogard 这样的人提出了反对使用它的好案例。

基本上，一个 Repository 很容易成为一个知道如何形成许多不同查询的大类，这违反了SRP。在复杂的系统中避免这种情况最终会为您提供大量的存储库，而在简单的系统中使用存储库只是过度设计。

于 2013-09-27T20:19:45.840 回答