数据集VS实体框架与存储过程 [英] Dataset vs Entity Framework with stored procedures

问题描述

整个问题已被重写，更清晰。

新建项目设计：

1. 在SQL服务器2012
2. 的Visual Studio 2012的.Net 4.5
3. 在业务逻辑将在存储过程执行
4. ASP.Net Web表单
5. 在WCF SOAP的XML Web服务与数据库的使用提供存储过程由DBA沟通
6. 在实体框架或数据集

在这里，我可以用数据集 - 没问题，但我想知道更详细的说明实体框架数据集上的优势。我一直在阅读有关实体框架的文章，我看到人们不得不使用EF数据集上，由于以下原因，更好的体验。

我想知道如果这些仍然是优势，我可以在我的情况下使用EF获得 - 数据库相关的动作总是做存储过程：

1. EF是很多更清洁，更容易维护和反对计划。 对EF ObjectContext的查询总是对数据库执行

2. 由于指定的对象和数据库之间的映射声明，而不是在code，如果你需要改变你的数据库模式，你可以c您必须修改尽量减少对$ C $的影响在应用程序 - 这样的系统提供了一个抽象层，这有助于从数据库隔离该应用。因此，EF可替换$ C $的一大块ç，否则你将不得不编写和维护自己。（如果存储过程的设计已被更改？）

3. 在英法特定结构的分离映射查询的过程中/塑造的建筑对象和跟踪变化的结果。

4. 数据集吸，尤其是在WCF情景（他们增加大量的开销用于处理内存中的数据操作） - >表示EF与WCF是更好的性能

？

解决方案

1。 EF是很多更清洁，更容易维护和程序对 - >>你能否解释..这是因为＃2以下

？

EF是一个对象关系映射（ORM），并在＃2注意将自动生成相关的数据库模式的对象。 EF是现成的一个抽象的数据访问层，并在当前版本实现了资源库的模式。这给了你好处，如LINQ，对象图CRUD操作，什么EF队认为是最佳做法通过.NET访问数据。

现成的功能和易用性与数据库（具体地说SQL Server）的整合可提供更易于维护和对程序。不过，也有在那里使用ORM可能不是最好的选择的情况下，你应该用谨慎判断。这里有一些场景来考虑不使用ORM（尤其是当你的球队没有EF的现有知识）：有限的数据查询，不复杂的应用程序，舒适的或使用你的数据访问层，你的申请截止日期是积极的，等见其他的选择，我说明如下。

2。如果您需要更改数据库架构，可以最大限度地减少在code，你在你的应用程序修改的影响 - >>如果一个存储过程的参数和返回的字段被改变？ EF仍然影响降到最低？

是的，EF生成基于关闭EDMX文件，该文件是简单数据库模式的XML文件。这包括更新映射到存储过程中的对象（注：这是不适用的，如果先用code，直到EF6被释放）。你可以改变一个存储过程和EF可以采取更新模式和更新code。但是，你必须解决您的code，你叫EF存储过程的方法和参数已经改变。您还可以使用的东西的LINQ to SQL如果您不舒服EF将提供存储过程调用的对象方法。

3。数据集吸，尤其是在WCF情景（他们增加大量的开销用于处理内存中的数据处理） - >>你能解释更多的

？

数据集吸显然是一个通用的声明。您可以使用数据集为他们的目的，考虑使用.NET处理内存中的数据。由于数据集是在内存中做一些简单的CRUD操作时，它们被认为是低效的。推荐使用存储过程和数据读取（一定要关闭它们，当读完数据）高效的数据读取与SQL数据库。

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

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

2. 使用动态库 - 小巧玲珑，ServiceStack ORM精简版，简单的POCO，简单的数据，海量

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

4. 其他奥姆斯 - NHibernate的是一个首选

。

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

New project design:

1. Sql Server 2012
2. Visual Studio 2012 .Net 4.5
3. Business logic will be implemented in stored procedures
4. ASP.Net Webforms
5. WCF SOAP XML Web Service to communicate with database using provided stored procedures by DBA
6. Entity Framework or Dataset

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.

I would like to know if these are still advantages that I can obtain using EF in my case - database related actions are always done with stored procedures:

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

2. 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?)

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

4. 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 is a lot cleaner and much easier to maintain and program against ->> can you elaborate?.. is this because of #2 below?

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.

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. If you need to change your database schema, you can minimize the impact on the code you have to modify in your applications ->> what if parameters and returned fields of a stored procedure are changed? EF still minimize the impact?

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. DataSets suck, especially in a WCF scenario (they add a lot of overhead for handling in-memory data manipulation) ->> Can you explain more?

"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.

There are other options besides EF out there:

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

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

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

4. Other ORMs - NHibernate is a top choice.

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