整个问题已被重写以更加清晰..
新项目设计：
- SQL Server 2012
- Visual Studio 2012.Net 4.5
- 业务逻辑将在存储过程中实现
- ASP.Net 网络表单
- WCF SOAP XML Web 服务使用 DBA 提供的存储过程与数据库进行通信
- 实体框架或数据集
在这里我可以使用数据集 - 没问题，但我想更详细地解释实体框架相对于数据集的优势。我一直在阅读有关实体框架的文章，并且由于以下原因，我发现人们使用 EF 比使用数据集有更好的体验。
我想知道在我的例子中使用 EF 是否仍然具有这些优势 - 与数据库相关的操作始终通过存储过程完成：
EF 更干净、更容易维护和编程。
针对 EF ObjectContext 的查询始终针对数据库执行
因为对象和数据库之间的映射是以声明方式指定的，而不是在代码中指定的，所以如果您需要更改数据库模式，您可以最大限度地减少对应用程序中必须修改的代码的影响——因此系统提供了一定程度的抽象有助于将应用程序与数据库隔离。因此，EF 可以取代您必须自己编写和维护的大量代码。（如果存储过程设计已更改怎么办？）
EF 经过专门构建，可将映射查询/塑造结果的过程与构建对象和跟踪更改分开。
数据集很糟糕，尤其是在 WCF 场景中（它们增加了处理内存数据操作的大量开销）-> 意味着 EF 与 WCF 的性能更好？
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，因为 EF 将提供存储过程调用作为对象方法。
3. DataSet 很糟糕，尤其是在 WCF 场景中（它们为处理内存数据操作增加了大量开销）->> 您能解释更多吗？
“数据集很糟糕”显然是一个笼统的说法。您使用数据集的目的是使用 .NET 处理内存中的数据。由于数据集位于内存中，因此在执行简单的 CRUD 操作时，它们被认为效率低下。建议使用存储过程和数据读取器（读取数据后请务必关闭它们），以便通过 SQL 数据库进行高效的数据读取。
除了 EF 之外还有其他选项：
自己动手 - 编写存储过程、使用数据读取器并映射到 POCO 对象
使用动态库 - Dapper、ServiceStack ORM Lite、简单 POCO、简单数据、海量
使用 LINQ to SQL - 轻量级数据访问层（仅适用于 SQL Server）
其他 ORM - NHibernate 是首选。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
