具有存储过程的数据集与实体框架

Question

整个问题已经改写得更清楚了..

新项目设计：

1. Sql Server 2012
2. Visual Studio 2012 .Net 4.5
3. 业务逻辑将在存储过程中实现
4. ASP.Net 网络表单
5. WCF SOAP XML Web 服务使用 DBA 提供的存储过程与数据库通信
6. 实体框架或数据集

在这里我可以使用 Dataset - 没问题，但我想在更详细的说明中了解 Entity Framework 相对于 Dataset 的优势。我一直在阅读有关实体框架的文章，并且由于以下原因，我看到人们在数据集上使用 EF 的体验更好。

我想知道这些是否仍然是我在我的情况下使用 EF 可以获得的优势 - 与数据库相关的操作总是通过存储过程完成：

1. EF 更简洁，更易于维护和编程。 针对 EF ObjectContext 的查询始终针对数据库执行

2. 因为您的对象和数据库之间的映射是通过声明方式而不是在代码中指定的，所以如果您需要更改数据库架构，您可以最大限度地减少对您必须在应用程序中修改的代码的影响——所以该系统提供了一个抽象级别，有助于将应用程序与数据库隔离开来。因此，EF 可以替换您必须自己编写和维护的大量代码。（如果存储过程设计已更改怎么办？）

3. EF 专门用于将映射查询/塑造结果的过程与构建对象和跟踪更改分开。

4. DataSet 很糟糕，尤其是在 WCF 场景中（它们为处理内存中的数据操作增加了很多开销）-> 意味着带有 WCF 的 EF 性能更好？

Answer 1

1. EF 更干净，更容易维护和编程 ->> 你能详细说明一下吗？.. 这是因为下面的 #2 吗？

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

开箱即用的功能以及与数据库（特别是 SQL Server）的轻松集成可以提供更易于维护和编程的功能。但是，在某些情况下，使用 ORM 可能不是最佳选择，您应该谨慎判断。以下是一些不使用 ORM 的场景（尤其是当您的团队缺乏当前的 EF 知识时）：有限的数据查询、不复杂的应用程序、舒适的编写或使用数据访问层、您的应用程序截止日期很紧迫等。请参阅我在下面提到的其他选项。

2。如果您需要更改您的数据库架构，您可以最大限度地减少对您必须在应用程序中修改的代码的影响 ->> 如果存储过程的参数和返回字段发生更改怎么办？ EF 仍将影响降至最低？

是的，EF 根据 EDMX 文件生成，该文件只是您的数据库架构的 XML 文件。这包括更新映射到您的存储过程的对象（注意：如果在 EF6 发布之前先使用代码，这不适用）。您可以更改存储过程，EF 可以采用更新后的架构并更新您的代码。但是，您将不得不修复调用 EF 存储过程方法并且参数已更改的代码。如果您对 EF 不满意，您也可以使用 LINQ to SQL，因为它将提供存储过程调用作为对象方法。

3.数据集很糟糕，尤其是在 WCF 场景中（它们为处理内存中的数据操作增加了很多开销）->> 你能解释更多吗？

“DataSets 很烂”显然是一个通用语句。您将 DataSet 用于它们的用途，即使用 .NET 处理内存中的数据。由于 DataSet 在内存中，因此在执行简单的 CRUD 操作时它们被认为是低效的。建议使用存储过程和数据读取器（数据读取完成后一定要关闭它们），以便与 SQL 数据库进行高效的数据读取。

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

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

2. 使用动态库 - Dapper、ServiceStack ORM Lite、简单 POCO、简单数据、海量

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

4. 其他 ORM - NHibernate 是首选。

Answer 2

这是为了回应乔纳森关于数据集的回答。因为评论允许内容太短，所以我把它作为答案。

这是旧的，但直到现在，使用 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 允许控制存储过程映射的非常小的细节，可以根据需要进行调整。关于批处理操作，Table adapters可以让你控制一次可以发送多少条语句，EF呢？ 1 by 1，想象一下你需要导入 10000 条记录，我对这个场景做了一个比较，没有办法用 EF 方式让它快速。如果更改了存储过程，请给我 30 秒的时间来修复 DataSet，要么重新生成它，要么手动修复它。你会发现它在 EF 中没有更快的速度。

EF 不可能比使用 DataSet 的 ADO.NET 更快。 EF 在使用 ADO.NET 更新数据库之前增加了解析 ExpressionTree、评估它、生成 SQL 语句的大量开销，EF 的底层是 ADO.NET。

我发现 DataSet 唯一不方便的是 DataRow 不是 POCO。序列化比较麻烦，需要映射到DataContract时会被WCF卡住，可以直接使用EF的POCO作为数据合约。

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