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

Question

整个问题已被重写为更清楚..

新项目设计:

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

在这里我可以使用数据集 - 没问题,但我想知道实体框架优于数据集的优势更详细的解释.我一直在阅读有关实体框架的文章,由于以下原因,我看到人们在使用EF over dataset方面有更好的经验.

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

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

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

3. EF的具体结构是将查询/整形结果与构建对象和跟踪更改的映射过程分开.

4. DataSets很糟糕,尤其是在WCF场景中(它们为处理内存数据操作增加了大量开销) - >意味着EF与WCF的性能更好？

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 suck"显然是一个通用声明.您可以将DataSet用于使用.NET处理内存中数据的目的.由于DataSet在内存中,因此在进行简单的CRUD操作时会被认为效率低下.建议使用存储过程和数据读取器(确保在读取数据时关闭它们),以便使用SQL数据库进行高效的数据读取.

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

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

2. 使用动态库 - Dapper,ServiceStack ORM Lite,简单POCO,简单数据,大规模

3. 使用LINQ to SQL - 更轻的权重数据访问层(仅适用于SQL Server)

4. 其他ORM - NHibernate是首选.