数据集与使用存储过程的实体框架

Question

整个问题已经重新编写，更加清晰明了。

新项目设计：

1. Sql Server 2012
2. Visual Studio 2012 .Net 4.5
3. 业务逻辑将在存储过程中实现。
4. ASP.Net Webforms
5. 使用DBA提供的存储过程与数据库通信的WCF SOAP XML Web服务。
6. Entity Framework或DataSet。

我可以使用 DataSet - 没有问题，但是我想知道 Entity Framework 相对于 DataSet 的优点更为详细的解释。我一直在阅读关于 Entity Framework 的文章，并且发现人们对 EF 的体验要比 DataSet 更好，因为以下原因。

请问这些是否仍然是我在此情况下使用 EF 可以获得的优势——与数据库相关的所有操作都使用存储过程进行：

1. EF 很干净，非常容易维护和编写程序。针对 EF ObjectContext 的查询总是针对数据库执行的。

2. 因为对象和数据库之间的映射是以声明方式而不是代码方式指定的，所以如果您需要更改数据库模式，则可以最小化需要修改应用程序中的代码的影响，因此该系统提供了一定的抽象层，有助于将应用程序与数据库隔离开来。因此，EF 可以取代您必须自己编写和维护的大量代码。(如果存储过程设计发生了变化，怎么办？)

3. EF 的结构专门为将查询映射/形状结果与构建对象和跟踪更改的过程分离而设计。

4. DataSets 糟糕，特别是在 WCF 方案中（它们增加了处理内存中数据操作的开销） -> 这意味着 EF 在性能上比带有 WCF 的 DataSet 更好吗？

- devphil

---

阅读这篇文章：http://blog.stackoverflow.com/2011/08/gorilla-vs-shark/ 并选择使用 EF。 - Sten Petrov

使用EF仍然比Dataset更好的选择吗？ - devphil

显然你没有阅读链接的博客文章。 - Sten Petrov

嗯... 是的，我同意这是一个像大猩猩对鲨鱼一样的问题，但你说大猩猩在这里赢了，因为你说“选择EF”。为什么选EF？只是因为Dataset是老技术吗？Microsoft会专注于EF而不是Dataset吗？即使我使用存储过程，ORM也比较好用？我应该用更详细的解释来说服我的团队选择EF。 - devphil

似乎这是一个需要更多讨论和一些更有经验的高级成员发表意见的话题。 - Zapnologica

Answer 1

1. EF的代码更加简洁易维护和编程 ->> 你能详细说明吗？.. 这是因为下面的#2吗？

EF是一种对象关系映射器(ORM)，它将自动生成与数据库架构相关的对象，就像#2中所述。EF是数据访问层的开箱即用抽象，当前版本实现了仓储库模式。这为您带来了诸如LINQ、对象图CRUD操作以及EF团队认为通过.NET访问数据的最佳实践等好处。

开箱即用的功能和与数据库(特别是SQL Server)的易于集成性可以提供更易于维护和编程的方法。然而，在某些情况下，使用ORM可能不是最佳选择，您应该使用审慎判断。以下是一些需要考虑不使用ORM的情况(特别是在您的团队缺乏当前EF知识时)：有限的数据查询、非复杂的应用程序、熟悉编写或使用数据访问层、您的应用程序截止期限紧迫等。请参见下面我提到的其他选项。

2. 如果您需要更改数据库架构，您可以最小化需要修改应用程序中的代码的影响 ->> 如果存储过程的参数和返回字段被更改了怎么办？EF仍然可以最小化影响吗？

是的，EF基于EDMX文件生成，这只是您的数据库架构的XML文件。这包括更新映射到您存储过程的对象(注意:如果使用Code First，直到EF6发布为止，这是不适用的)。您可以更改存储过程，EF可以获取更新的架构并更新您的代码。但是，您将需要修复在调用EF存储过程方法时更改了参数的代码。您还可以使用LINQ to SQL，如果对EF不熟悉，它将提供存储过程调用作为对象方法。

3. 数据集很糟糕，特别是在WCF场景下(它们增加了处理内存中数据操作的开销) ->> 你能解释更多吗？

数据集(DataSets)在WCF情况下表现不佳，因为它们会为处理内存中数据操作增加负担。数据集是一种.NET Framework的组件，用于在内存中保存和维护数据之间的联系，并支持对这些数据执行多种操作。然而，当涉及大量数据时，数据集可能会导致性能问题和内存泄漏。相反，使用ORM框架如EF或Dapper能够更好地处理数据操作，同时减少内存开销和提高性能。

"DataSets suck"这个说法显然是一个泛泛而谈的陈述。你应该在.NET中使用DataSets来处理内存中的数据，因为这正是它们设计的初衷。由于DataSets是在内存中进行操作的，因此在进行简单的CRUD操作时效率较低。建议使用存储过程和数据读取器（在读取完数据后记得关闭它们）来实现与SQL数据库的高效读取。

除了EF之外，还有其他的选择：

1. 自己动手 - 编写存储过程，使用数据读取器，并映射到POCO对象

2. 使用动态库 - Dapper、ServiceStack ORM Lite、Simple POCO、Simple Data、Massive

3. 使用LINQ to SQL - 更轻量级的数据访问层（仅适用于SQL Server）

4. 其他ORM - NHibernate是最佳选择。

- Jonathan Harrison

Answer 2

这是对Jonathan有关DataSet的回答。由于评论允许内容太短，因此我将其作为答案发布。

虽然这是旧话题，但到现在为止，使用EF6和EF dotnet core，我发现仍然可以就此问题进行争论。

我正在寻找有关此主题的意见，并最终找到了这篇文章。老实说，我非常不同意Jonathan关于DataSet的说法。

针对“由于DataSets存在于内存中，因此在执行简单的CRUD操作时效率低下”的观点，我相信EF的DbContext也存在于内存中，并且离线数据处理不仅适用于DataSet，还适用于LinQ2SQL和EF。使用DataTableAdapter和CommandBuilder可以完成简单的CRUD操作，无需编写单个SQL语句。 DataSet是ADO.NET的一部分，我们不能说ADO.NET推荐存储过程或其他内容，它必须支持访问数据库的所有方式，实际上DataSet不访问数据库，而是DataTableAdapter，DataReader和DbCommand进行访问。

如果您使用Visual Studio的Typed DataSet，则会发现它在存储过程映射和批量操作方面比EF优秀得多。我的项目有5000个存储过程，并且映射到EF很痛苦，如果声明不受EF支持，则EF会抛出许多种错误。另一方面，Typed DataSet允许控制存储过程映射的非常小的细节，可以根据您的需求进行弯曲。关于批量操作，表适配器允许您控制一次可以发送多少条语句，那么EF呢？逐个查找，想象一下您需要导入10000条记录，我对这种情况进行了比较，无法通过EF方式快速完成。如果存储过程发生变化，请给我30秒来修复DataSet，无论是重新生成还是手动修复，它都不会比EF更快。

使用DataSet时唯一不方便的事情是DataRow不是POCO。它很难序列化，使其在必须将其映射到DataContract时在WCF中无用，您可以直接使用EF的POCO作为数据合同。

对于那些需要处理大量数据，批量更新，存储过程的项目，请远离EF。我给EF太多机会参与企业项目，但最终我不得不为它们使用Typed DataSet。我仍然在寻找意见，因为我仍然希望EF能够满足我的需求。我确实喜欢EF方法的简单性，但与Typed DataSet相比，它仍然太年轻。

- Khoa Nguyen

---

Khoa - 感谢反馈，但需要明确的是，我并没有说数据集比EF差或建议使用EF，实际上我不喜欢EF，这根本不是一个可比较的事情。我在讨论EF的优缺点，以便读者可以根据工作需要选择合适的工具。关于数据集效率低下的观点与其在Web应用程序（或WCF）中的使用有关，通常情况下，对于请求/响应服务（例如，我更喜欢使用DTO和Dapper的CQRS模式），数据集是过度设计。数据集的主要用例是需要断开连接的内存数据操作的应用程序。 - Jonathan Harrison

简而言之，我的观点是：“如果您有一个简单的CRUD应用程序，可以使用EF。如果它是具有大量数据访问（批量更新、存储过程）的应用程序，则应选择支持这些功能的工具。” - Khoa Nguyen

我喜欢这样的事情，四年后的评论与四年前的原帖作者产生互动。这就是真正的社区！感谢你们两个帮助我决定DS和EF的问题。 - RobertSF

好的回答，你是一个诚实的人。在过去，我会自己创建一种新的数据集结构，并让 MS 类型数据集图表编辑器为我的数据集生成代码，这使得 DataRow 支持并发访问。多么美好的一天！将表格拖放到图表编辑器中，获取 ER 模型和类型化的数据集代码，并立即与 GUI 一起使用。 - Inshua