Enterprise library 和 Entity Framework 之间的关系 - ADO.Net 技术的各种产品

Question

我正在阅读this 非常有趣的关于实体框架（EF）的书，这是微软提供的对象关系映射器（ORM）产品。我开始回溯 Microsoft 提供的所有产品，以通过其专有的 ADO.NET 数据提供程序技术连接到数据库。早在十年前，我通过直接引用我项目中的相应 DLL 文件来使用 Microsoft 应用程序块，但从那时起出现了很多事情。因此，我开始研究每当我从头开始一个新项目时应该使用哪个选项，以及这些产品如何真正相互叠加，或者它们只是对相同技术 ADO.NET 的逐步增强，而 EF 是最新的：

1. 手动使用 System.Data.SqlClient 命名空间中可用的各种 ADO.NET 类（通过引用 System.Data.dll - 自 .NET 框架 1.x 起可用）
2. 直接在您的项目中引用 Microsoft.ApplicationBlocks.Data.dll 程序集并执行 DB 查询。
3. Microsoft 模式和实践团队的企业库。
4. LINQ to Sql（随 .NET v3.5 发布）
5. 实体框架（随 .NET v3.5 Service Pack 1 发布）

一旦我进入 ADO.NET 世界，所有这些事情都可能成为真正的困惑点。如果有人能对这些产品有一个好的鸟瞰图，那将非常有帮助。

Answer 1

随手 - 您应该注销 Microsoft.ApplicationBlocks.Data 和 Enterprise Library。

LINQ to SQL 支持 Microsoft SQL Server 中可用的数据库表、视图、存储过程和函数的一对一映射。它适用于 RAD（快速应用程序开发）场景。我相信 MS 仍然支持它，但我不认为他们正在积极开发它。我多年来没有使用过它，也没有看到它用于我从事的任何项目。

正如您提到的，Entity Framework 是一个 ORM，它比 LINQ to SQL 强大得多。以下SO 帖子有很多关于差异的信息。

另一个需要考虑的选项是Dapper。 Dapper 是一种微型机器，速度非常快。这是这篇 SO 帖子中对 Dapper 与 ADO.NET 的一些很好的分析：Why should one use Dapper ? Also can anyone comment on Dapper Vs ADO.NET Pros and Cons

就个人而言，我在构建应用程序时使用实体框架或 Dapper。如果它是一个具有复杂映射要求的非常大的应用程序——那么我通常会选择实体框架。否则，我坚持使用 Dapper。

如果我正在构建不需要任何类型映射的服务或某些实用程序，我可以直接使用 ADO.NET。

阅读此EntityFramework VS pure Ado.Net