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

Dataset vs Entity Framework with stored procedures(具有存储过程的数据集与实体框架)

问题描述

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

The whole question has been rewritten to be more clear..

新项目设计:

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 的体验更好.

Here I can use Dataset - no problem, but I would like to know the advantage of Entity Framework over Dataset in more detailed explanation. I've been reading articles about entity framework, and I saw people had better experience using EF over dataset due to following reasons.

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

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

1. EF is a lot cleaner and much easier to maintain and program against. Queries against the EF ObjectContext are always executed against the database

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

Because the mapping between your objects and your database is specified declaratively instead of in code, if you need to change your database schema, you can minimize the impact on the code you have to modify in your applications--so the system provides a level of abstraction which helps isolate the app from the database. The EF can therefore replace a large chunk of code you would otherwise have to write and maintain yourself.(What if stored procedure design has been changed?)

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

The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes.

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

DataSets suck, especially in a WCF scenario (they add a lot of overhead for handling in-memory data manipulation) -> means EF with WCF is better in performance ?

推荐答案

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

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

EF is an Object Relational Mapper (ORM) and will automatically generate objects related to your database schema as noted in #2. EF is an out-of-box abstraction for your data access layer and in the current version implements a repository pattern. This gives you benefits such as LINQ, object graph CRUD operations, and what the EF team deems as best practice for accessing data via .NET.

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

The out-of-box functionality and ease of integration with the database (specifically SQL Server) can provide easier to maintain and program against. However, there are situations where using an ORM may not be the best option and you should use prudent judgement. Here are some scenarios to think about not using an ORM (especially when your team lacks current knowledge of EF): limited data queries, non-complex application, comfortable writing or using your data access layer, your application deadline is aggressive, etc. See other options I noted below.

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

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

Yes, EF generates based off of EDMX file which is simply an XML file of your database schema. This includes updating objects that map to your stored procedures (NOTE: this is not applicable if using code first until EF6 is released). You can alter a stored procedure and EF can take the updated schema and update your code. However, you will have to fix your code where you called EF stored procedures methods and the parameters have changed. You can also use something LINQ to SQL if you are uncomfortable with EF which will provide stored procedure calls as object methods.

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

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

"DataSets suck" is obviously a generic statement. You use DataSets for what they are intended for which is dealing with data in memory using .NET. Since DataSets are in memory they are considered inefficient when doing simple CRUD operations. It is recommended to use stored procedures and data readers (be sure to close them when done reading data) for efficient data reads with SQL database.

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

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

1. Do it yourself - Write stored procedures, use data readers, and map to POCO objects

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

Use a Dynamic Library - Dapper, ServiceStack ORM Lite, Simple POCO, Simple Data, Massive

使用 LINQ to SQL - 轻量级数据访问层(仅适用于 SQL Server)

Use LINQ to SQL - Lighter weight data access layer (Only for SQL Server )

其他 ORM - NHibernate 是首选.

Other ORMs - NHibernate is a top choice.

这篇关于具有存储过程的数据集与实体框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！