C# 中这几个主流的 ORM（对象关系映射器）：Dapper、Entity Framework (EF) Core 和 EF 6

我们来详细地比较一下 C# 中这几个主流的 ORM（对象关系映射器）：Dapper、Entity Framework (EF) Core 和 EF 6。它们各有其设计哲学、优缺点和适用场景。

我会从多个维度进行对比，并给出总结和建议。

---

1. Entity Framework 6 (EF6)

EF6 是 .NET Framework 时代官方的、功能全面的 ORM，现在已进入维护模式，新项目应优先考虑 EF Core。

• 类型: 全功能、重量级 ORM。
• 开发方: Microsoft。
• 状态: 成熟稳定，但仅支持 .NET Framework，新功能开发已停止。
• 核心特性:
  • DB First / Model First: 从数据库生成模型，或从设计器画模型生成数据库。
  • Code First: 用 C# 类定义模型，EF 负责创建或迁移数据库 schema。这是现在的主流方式。
  • 变更跟踪: 强大的变更跟踪器。你查询出的实体，修改其属性后，调用 SaveChanges 即可更新数据库，无需写 SQL。
  • LINQ 提供程序: 非常强大，可以将复杂的 LINQ 查询转换为高效的 SQL（大部分情况下）。
  • 丰富的关联关系: 轻松处理一对一、一对多、多对多关系，支持延迟加载（Lazy Loading）、贪婪加载（Eager Loading）和显式加载（Explicit Loading）。

---

2. Entity Framework Core (EF Core)

EF Core 是 EF6 的现代化、轻量级、跨平台重写版本，是当前 .NET 平台的官方推荐 ORM。

• 类型: 全功能、轻量级、跨平台 ORM。
• 开发方: Microsoft。
• 状态: 积极开发，是 .NET 5+ 和 .NET Core 的现代标准。
• 核心特性:
  • 继承了 EF6 的大部分优点（Code First，变更跟踪，LINQ，关系处理）。
  • 跨平台: 支持 Windows, Linux, macOS。
  • 更轻量、性能更好: 相比 EF6，架构更简洁，性能有显著提升。
  • 更灵活:
    • 支持非关系型数据库（如 Azure Cosmos DB），但主要功能还是针对关系型数据库。
    • 支持全局查询过滤器（如软删除过滤）。
    • 更好的并发控制机制。
  • 与 EF6 的主要区别:
    • 延迟加载是可选功能，需要安装 Microsoft.EntityFrameworkCore.Proxies 包并显式启用。
    • 某些高级映射模式（如表拆分）在 EF Core 中实现方式不同或尚未支持。
    • LINQ 查询的翻译能力在不断提升，但早期版本可能不如 EF6 强大，现在已非常成熟。

---

3. Dapper

Dapper 是由 StackOverflow 团队开发的一个微ORM（Micro-ORM）。它不是一个全功能的 ORM，而是一个扩展了 IDbConnection 接口的轻量级 helper 库。

• 类型: 微 ORM，轻量级扩展。
• 开发方: StackExchange (StackOverflow)。
• 状态: 非常成熟稳定，功能基本固定。
• 核心特性:
  • 极致性能: 它的速度接近原生的 ADO.NET，因为它的实现几乎就是生成参数化 SQL 并高效地将数据库返回的数据映射到对象上。其性能远超任何全功能 ORM。
  • 无抽象泄漏: 你几乎总是需要自己写 SQL 查询。你对你执行的 SQL 有完全的控制权，没有“魔法”，也就避免了 ORM 生成低效 SQL 的风险。
  • 无变更跟踪: 它只做一件事：查询映射和执行命令。你需要自己管理实体的状态（新增、修改、删除）。
  • 简单: API 非常简洁，主要方法就是 Query<T>, QueryFirstOrDefault<T>, Execute 等。

---

对比表格

特性维度	Dapper	Entity Framework Core	Entity Framework 6
类型	微ORM	全功能 ORM	全功能 ORM
性能	⭐️⭐️⭐️⭐️⭐️ (最快)	⭐️⭐️⭐️ (良好，持续优化)	⭐️⭐️ (较重，相对较慢)
开发速度	慢 (需要手写SQL)	快 (自动化，代码优先)	快 (自动化，代码优先)
控制力	完全控制 (手写SQL)	低 (由ORM生成SQL)	低 (由ORM生成SQL)
学习曲线	平缓 (SQL知识+简单API)	陡峭 (概念多，行为复杂)	陡峭 (概念多，行为复杂)
变更跟踪	无	有	有
LINQ 支持	有限 (仅用于简单查询)	强大 (支持复杂查询)	强大 (支持复杂查询)
数据库支持	所有支持 ADO.NET 的 DB	多种关系/非关系DB	多种关系型DB
跨平台	是 (.NET Standard)	是 (.NET Core/.NET 5+)	否 (.NET Framework only)
适用场景	高性能、复杂查询、报告	快速开发、业务逻辑复杂、CRUD	遗留 .NET Framework 项目

---

如何选择？

选择 Dapper 当：

1. 性能是首要考虑因素：例如在高吞吐量、低延迟的应用程序中（如 StackOverflow 这种网站）。
2. 需要对 SQL 进行极致优化：你有复杂的查询、存储过程，或者需要充分利用特定数据库的高级功能，不希望 ORM 的抽象妨碍你。
3. 项目主要是报告或读取数据：你需要执行大量不同的、复杂的查询，并将结果快速映射到对象。
4. 你更喜欢或要求手写 SQL：你的团队对 SQL 非常熟悉，并且希望完全控制所有数据库交互。

选择 Entity Framework Core 当：

1. 开发速度是关键：你想要快速构建应用程序，专注于业务逻辑而不是数据库脚本。
2. 丰富的领域模型：你的业务逻辑复杂，涉及大量的实体和关系，变更跟踪和状态管理能为你节省大量代码。
3. 代码优先是首选：你希望用 C# 代码来定义数据库结构，并享受自动迁移（Migrations）带来的便利。
4. 使用 LINQ 进行强类型查询：你希望用编译时检查的 LINQ 来编写查询，避免 SQL 字符串在运行时出错。
5. 应用程序需要支持多种数据库：EF Core 的数据库提供程序模型使得更换底层数据库（如从 SQL Server 切换到 PostgreSQL）变得相对容易。

关于 Entity Framework 6：

• 除非你正在维护一个现有的、基于 .NET Framework 的项目，并且没有升级到 .NET Core/.NET 5+ 的计划，否则新项目不应该选择 EF6。 所有新项目都应首选 EF Core。

混合使用模式

在许多中大型项目中，一种常见的混合模式是：

• 使用 EF Core 处理 95% 的标准 CRUD 操作。利用其开发效率高的优势，快速完成大多数的增删改查任务。
• 使用 Dapper 处理另外 5% 的复杂、高性能查询。例如复杂的报表查询、大屏数据展示等，这些场景下你可以手写优化 SQL，用 Dapper 执行并获得极致性能。

你可以很方便地在同一个项目中同时引用 Microsoft.EntityFrameworkCore 和 Dapper，根据不同的场景选择最合适的工具。

总结

	Dapper	EF Core
口号	“你来写 SQL，我来帮你映射。”	“忘掉数据库，专注于你的对象。”
本质	一个强大的 ADO.NET 扩展	一个真正的 对象关系映射器
哲学	简单、透明、可控、高性能	自动化、抽象、开发效率、集成度

最终的选择取决于你的项目需求、团队技能和对性能与控制力的权衡。没有绝对的“最好”，只有“最合适”。