企业库与实体框架之间的关系 - ADO.Net技术的各种产品

Question

我正在阅读有关实体框架的this非常有趣的书，当我开始回溯微软通过其专有的ADO.Net数据提供商技术连接到数据库的所有产品时，这是一个来自Microsoft的ORM产品。十年前，我曾经通过直接引用我项目中相应的dll文件来使用Microsoft应用程序块，但从那以后出现了很多东西。因此，每当我从头开始一个新项目以及这些产品如何真正相互堆叠或者它们只是逐渐增强同一技术ADO.Net并且EF是最新的时，我就开始研究运动的选项：

1. 手动使用System.Data.SqlClient命名空间中提供的各种ADO.Net类（通过引用System.Data.dll - 自.Net framework 1.x起可用）
2. 直接在项目中引用Microsoft.ApplicationBlocks.Data.dll程序集并执行数据库查询。
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中可用的数据库表，视图，Sproc和函数的1对1映射。这对RAD（快速应用程序开发）场景很有用。我相信MS仍然支持它，但我不认为他们正在积极开发它。我没有使用它，或者看到它用于我多年来一直在进行的任何项目。

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

另一个需要考虑的选择是Dapper。小巧玲珑是一个微观，非常快。以下是对这篇SO帖子中的Dapper与ADO.NET的一些很好的分析：Why should one use Dapper ? Also can anyone comment on Dapper Vs ADO.NET Pros and Cons

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

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

阅读此EntityFramework VS pure Ado.Net