.NET生态主流ORM选型指南：EF Core、Dapper、SqlSugar对比与实战

做.NET开发的人应该都有过这种纠结：项目里到底该用哪个ORM？这问题看着简单，真到了拍板的时候，很多人还是靠惯性——别人用EF Core我也用，老项目用Dapper就一直用。我以前带团队做某跨平台系统时，前期在EF Core和Dapper之间反复横跳，中途换了一次数据访问层，返工量比想象中大得多。从那以后，我把.NET生态里主流ORM的文档、源码、Issue挨个过了一遍，才算建立起一套相对清晰的判断标准。

这篇博文就是那段时间的总结。我会把当前.NET生态里主流的几个ORM——EF Core、Dapper、SqlSugar、Nhibernate、RepoDb，逐一拆开讲：每个框架的核心能力、最适合的场景、常见的坑，以及同一个业务需求在不同框架下的写法和差异。不管你是刚接触.NET的初学者，还是正在做技术选型的老手，都可以把这份内容当作“ORM选型速查手册”来用，省去大量翻官方文档的成本。

1. 为什么需要ORM：先理解“对象和关系的阻抗失配”

1.1 纯ADO.NET的痛点在哪里

先说一个基础问题：为什么不用纯ADO.NET？能用，而且性能上限最高，但代价是大量重复代码。比如一个简单的用户表插入操作，纯ADO.NET要写连接字符串、打开连接、创建命令、拼接参数、执行、关闭释放，六个步骤一步不能少。如果项目里有几十张表、上百个查询方法，代码量会相当可观。

更麻烦的是，参数类型和字段映射完全靠人肉维护。数据库字段一旦改名，编译期根本发现不了，运行到那条SQL才会炸。时间一长，项目里到处是复制粘贴过来的SQL片段，改起来提心吊胆。这就是很多团队转ORM的最初动机：让框架帮我们处理映射，把主要精力放回业务逻辑上。

1.2 ORM到底帮我们解决了什么

ORM解决的核心问题，行业内叫“对象和关系的阻抗失配”。数据库里是行和列，代码里是类和对象，两者之间天然存在语义落差。ORM就是这一层的翻译官。

完整功能的ORM会把表映射成实体类，把SQL查询封装成强类型API，甚至帮你自动维护数据库表结构。轻量ORM则保留SQL的灵活性，只做结果集到对象的映射。这两种路线没有绝对的优劣，关键看项目场景。搞清楚这一点，选型才有依据，否则就是跟风。

1.3 .NET生态ORM的总体格局

我把.NET生态里的ORM大致分成三个档位：

• 全功能ORM：EF Core、Nhibernate，主打自动映射、查询跟踪、状态变更、迁移工具，适合业务复杂、表关系多的项目。
• 轻量微型ORM：Dapper最典型，只做结果映射，SQL自己写，性能接近手写ADO.NET。
• 混合型框架：SqlSugar、RepoDb，介于两者之间，既要有全功能ORM的便利，又想保留一定的SQL控制力。

这个分档不是严格定义，只是帮大家建立一个整体印象。实际选型时，框架之间的边界其实很模糊，后面我会用真实代码来说明。

2. 主流ORM逐个拆解：定位、特色与适用边界

2.1 EF Core：功能最全的官方方案

EF Core是官方平台技术团队维护的ORM，也是.NET平台上的事实标准。它的核心能力大致有这几块：

• 实体映射与配置：支持Data Annotation和Fluent API两种方式，Code First、Database First都能覆盖。
• 强类型查询：LINQ表达式直接翻译成SQL，复杂的联表、分组、聚合都用强类型表达，编译期就能发现一部分字段写错的问题。
• 变更追踪：DbContext统一维护实体状态，调用SaveChanges时自动生成对应的增删改SQL。
• 数据库迁移：实体变更后通过命令行生成迁移脚本，能自动同步数据库结构，这在迭代快的项目里非常实用。
• 扩展能力：影子属性、值转换、全局查询过滤器、Owned Entity、继承映射等，适合承载相对复杂的领域模型。

EF Core最大的优势是开发效率高，尤其适合数据库结构跟着业务一起演进的项目。但抽象层级高，一旦生成的SQL性能不理想，排查成本会比手写SQL高得多。还有个常见坑：默认查询会把实体放进内存跟踪，查询结果量大时内存占用容易失控，必须主动用AsNoTracking()。

2.2 Dapper：性能标杆，把SQL控制权还给你

Dapper的定位非常明确：做“对象映射器”，不做“对象关系映射器”。它不帮你生成SQL，而是提供一系列扩展方法，让你把SQL字符串和参数对象传进去，然后把查询结果自动映射成实体类或动态对象。

核心功能其实不多，但个个实用：

• Query、QueryAsync、Execute、ExecuteAsync等基础方法，支持标量、单对象、集合、多结果集。
• 参数化查询是天然内置的，只要传入参数对象，SQL注入风险就很小。
• Dapper.Contrib扩展可以标注表名、主键、忽略字段等特性，做基础CRUD封装。
• 性能常年排在.NET ORM基准测试前列，映射路径极短。

Dapper适合SQL逻辑复杂、对性能敏感、团队里数据库角色话语权比较强的项目。缺点是SQL全部手写，实体字段变了要手动同步，项目大了以后维护成本会涨。另外，如果大量业务就是简单单表CRUD，用Dapper并不省事，这方面反而是SqlSugar这类框架更顺手。

2.3 SqlSugar：国产框架里功能与性能的平衡者

SqlSugar是国内团队维护的ORM，这几年在中文社区讨论度很高。设计理念是“简单、高性能、全功能”，在开发便利性和SQL可控性之间取了不错的平衡。

几个特色值得单独说：

• 查询语法友好：同时支持Lambda表达式和接近SQL的写法，从SQL转过来的开发者上手很快。
• 分页和联表封装成熟：内置分页方法、联表查询、Mapper映射，写起来干净利落。
• 多数据库适配：MySQL、SqlServer、PostgreSQL、SQLite、Oracle都有支持，切换成本低。
• 代码生成器：按数据库表反向生成实体类，还能生成简单三层代码，对中小型项目来说很省事。
• 实体能力丰富：自动填充、软删除、全局过滤、多租户等功能都有，很多是EF Core要配一堆代码才能实现的。

还有一点暗含的优势：中文文档为主，对国内团队学习成本极低。社区里很多坑都有人趟过，遇到问题搜中文关键词往往就能找到答案。

2.4 Nhibernate：老牌劲旅，胜在稳定成熟

Nhibernate是Java生态里Hibernate的.NET移植版本，资历最老的ORM之一。它和EF Core走的是同一条“全自动”路线，但设计理念更贴近传统领域模型驱动。

Nhibernate的长处：

• 延迟加载和一级、二级缓存机制非常成熟，处理复杂对象图时表现稳定。
• 映射方式多样，支持XML映射、特性映射、第三方FluentNhibernate。
• 单元工作（Unit of Work）实现得相当彻底，生命周期管理细腻。
• 在既有企业级领域模型的系统上，它依然是可靠选择。

但要承认，Nhibernate学习曲线陡，配置繁琐，文档偏老。新项目选它的人确实在减少，如果团队里没人熟悉它的套路，谨慎入场。

2.5 RepoDb：模块化混合路线的另一种尝试

RepoDb是一个混合型开源ORM，定位介于Dapper和EF Core之间。提供Dapper那样的SQL执行方式，同时也有基于表达式树的查询构造器，还支持批量操作、缓存、跟踪。

亮点集中在：

• 批量CRUD性能非常强，超过大多数ORM。
• 支持表达式构造查询条件，不必全部手写SQL字符串。
• 模块化设计，按需引用功能，依赖包很小。

但它在国内讨论度低，中文资料少。项目一旦遇到问题，能搜到的帮助有限。我的建议是：除非团队里有人愿意读英文文档甚至源码，否则生产环境项目不太建议首选RepoDb。

3. 同题实做：一个查询需求在四种ORM下的写法和对比

纸上谈兵没有说服力，我用一个常见的订单查询场景来对比：查询最近7天某个状态的订单，联查用户昵称，按下单时间倒序分页。分别在EF Core、Dapper、SqlSugar里实现一遍。

3.1 EF Core实现：强类型加LINQ

先定义实体和DbContext基础结构：

public class User { public int Id { get; set; } public string Nickname { get; set; } } public class Order { public int Id { get; set; } public int UserId { get; set; } public int Status { get; set; } public DateTime CreateTime { get; set; } } public class AppDbContext : DbContext { public DbSet<User> Users { get; set; } public DbSet<Order> Orders { get; set; } }

查询代码：

using var db = new AppDbContext(); var startTime = DateTime.Now.AddDays(-7); var page = await db.Orders .AsNoTracking() .Where(o => o.Status == 1 && o.CreateTime >= startTime) .OrderByDescending(o => o.CreateTime) .Skip((pageIndex - 1) * pageSize) .Take(pageSize) .Join(db.Users, o => o.UserId, u => u.Id, (o, u) => new { OrderId = o.Id, UserName = u.Nickname, o.CreateTime }) .ToListAsync();

这个写法的好处是全程强类型，实体字段写错了编译期就会提示。但有两个点要注意：一是展示场景记得加AsNoTracking()，避免实体被无谓跟踪；二是Join的字段在数据库里要有对应索引，否则数据量上来后生成的SQL会走全表扫描。EF Core的问题往往不在代码层，而在你没法完全预料生成出来的SQL长什么样。

3.2 Dapper实现：SQL完全可控

using var conn = new SqlConnection(connectionString); var sql = @" SELECT o.Id, o.CreateTime, u.Nickname FROM Orders o INNER JOIN Users u ON o.UserId = u.Id WHERE o.Status = @Status AND o.CreateTime >= @StartTime ORDER BY o.CreateTime DESC OFFSET @Offset ROWS FETCH NEXT @PageSize ROWS ONLY"; var orders = await conn.QueryAsync<OrderView>(sql, new { Status = 1, StartTime = startTime, Offset = (pageIndex - 1) * pageSize, PageSize = pageSize });

Dapper的多表映射如果用splitOn参数，是新手最常踩的坑。它本质是告诉Dapper“从哪一列开始算第二个对象的字段”，字段名一旦撞车，结果错乱还不报错。所以我这里直接用了一个OrderView扁平类，绕开拆分的复杂度。性能上Dapper确实快，但要留个心眼：OFFSET分页在数据量很大的时候性能会明显下降，生产环境更推荐游标分页或基于索引键的WHERE分页。

3.3 SqlSugar实现：简洁高效

var list = await db.Queryable<Order>() .Where(o => o.Status == 1 && o.CreateTime >= startTime) .OrderBy(o => o.CreateTime, OrderByType.Desc) .Skip((pageIndex - 1) * pageSize) .Take(pageSize) .LeftJoin<User>((o, u) => o.UserId == u.Id) .Select((o, u) => new OrderView { Id = o.Id, UserName = u.Nickname, CreateTime = o.CreateTime }) .ToListAsync();

注意这里和EF Core看起来很像，但SqlSugar的语法从SQL转过来的人更容易理解，执行过程也相对容易预期。而且它有内置的ToPageList方法，能直接返回分页列表加总条数，省掉一次手动Count查询。整体感觉是“文档说能做的，基本都能很顺滑地完成”，这在ORM里确实难得。

3.4 背后的取舍逻辑

把三种框架放到一起看，差异非常清晰：

我的观点很直白：没有哪个ORM在所有场景都占优。一个项目里既有复杂业务模型，又有大量报表查询时，拆开用两个是完全常见的做法——EF Core或SqlSugar管业务模型，Dapper管报表和批量读写。

4. 选型决策实践：不同类型项目该怎么选

4.1 按项目类型给推荐组合

根据我这些年实际接触的项目，可以按类型直接给一个参考结论：

• 微服务架构：每个服务通常表不多、领域边界清晰，建议Dapper或SqlSugar。EF Core也能用，但要特别注意迁移管理、性能优化这些问题。
• 老旧大型单体系统：如果原本就是Nhibernate或EF6，建议继续沿用成熟方案，别为了“新”随便重写数据访问层，风险很大。
• 轻量内部工具、管理后台：SqlSugar和EF Core都行，其中SqlSugar的代码生成器能省不少事。
• 高并发网关、读写分离架构：Dapper是优先选择，SQL直接可控，映射路径短，性能损耗最小。

4.2 选型还要看团队的技术底子

选型时还有一个容易被忽略的因素：团队里谁能维护这套ORM？

如果负责的人对状态跟踪理解不深，EF Core很容易写出性能很差的代码。比如我踩过的一次坑：某系统里用EF Core做批量更新，有人用foreach循环逐个SaveChanges，几千条数据直接打满数据库连接，接口大面积超时。后来排查半天才发现问题根源不是ORM不行，而是对它的状态管理机制理解不够。

如果真的在意长期维护成本，选型前要盘一盘团队底子：EF Core的问题靠官方文档能解决但路径长，Dapper的问题靠SQL功底能解决但SQL会多，SqlSugar的问题靠中文社区能解决但有人会嫌它不够“标准”。没有标准答案，只有权衡。

还有一个建议：无论选哪个ORM，都在仓储层做一层薄薄的封装，对外只暴露领域方法。我参与过的某跨平台系统，早期用的是EF Core，后来因为性能要求越来越高，在不动业务代码的前提下，花三天时间把仓储实现换成了Dapper。正是因为业务层和ORM隔开，这次替换才没伤筋动骨。

5. 高频问题与排查技巧实录

5.1 EF Core的高频坑

• N+1查询问题：延迟加载导航属性时，循环访问子实体会产生大量查询。解决办法是Include/ThenInclude预加载，或直接用Select投影成DTO，不给懒加载机会。
• 跟踪实体过多：查询默认按跟踪模式处理，大列表场景必须AsNoTracking。有些项目一个请求查几百条大对象，不关跟踪，GC压力直接上升。
• 迁移文件冲突：多分支同时加字段，合并后迁移文件冲突。解决办法是团队规定统一更新迁移文件，或者只让一个人负责合迁移。
• 参数化带来的执行计划不稳定：EF Core默认把变量参数化，这是好事，但一些复杂查询会因此得不到精确执行计划。极端情况可以改用FromSqlRaw并主动加查询提示。

5.2 Dapper的坑

• splitOn映射错乱：多表映射时splitOn写错，数据对不上但不报错。建议避免复杂拆分，多用扁平映射类。
• 连接管理容易疏漏：Dapper不管理连接，用完必须手动关闭。连接字符串泄漏、连接池耗尽这类问题几乎都是忘了释放连接。
• 存储过程的输入输出参数：DynamicParameters的方向要设置正确，漏掉输出参数会导致拿不到返回值，排查起来很隐蔽。

5.3 SqlSugar的坑

• 升级API变化：版本迭代快，升级前必须看升级日志，直接从老版本跨大版本容易遇到编译错误。
• 实体特性遗漏：主键、自增、忽略字段等特性如果和数据库不一致，运行期会出现奇怪异常。每次动表结构，记得回头检查实体。
• 数据库方言差异：大多数语法被框架抹平了，但批量更新、特定函数的实现在不同数据库下行为可能不完全一致，跨库项目要格外小心。

5.4 通用排查三步法

遇到ORM相关异常，先分清问题在哪一层：数据库层（索引、锁、死锁）、ORM层（SQL不对、映射错误）、业务层（逻辑本身有问题）。最快的定位方法就是先看ORM生成的SQL。

• EF Core可以用ToQueryString()方法拿到SQL。
• SqlSugar可以用ToSql()或调试输出接口看到SQL。
• Dapper本来SQL就是我们手写的，发现问题直接检查和优化SQL即可。

拿到SQL之后，在数据库客户端手动跑一遍，对比结果和预期，基本几分钟就能缩小范围。这套“生成SQL、手动执行、对比结果”的三步法，几乎能解决我遇到的七八成ORM问题。

6. 最后分享一点自己的体会

ORM这个东西，现在给我的感觉更像做饭用的锅——有人说铁锅好，有人说不粘锅好，但没有一口锅适合所有菜。如果你的项目正在纠结选型，我建议不要只看性能基准，也不要只看同事的推荐。拿当前项目里的两三个核心需求，分别用候选框架写出原型，自己跑一下，数据量按生产环境的十分之一来压，再对比代码量和后续维护体验，这个方法比网上千篇一律的对比文章靠谱得多。

还有一个小技巧：不论选哪套ORM，尽量把它隔离在仓储层后面，对外暴露业务语义明确的方法。这样哪天项目需要换数据访问方案，动的只有底层实现，业务代码不动。我在之前的项目里从EF Core切到Dapper，三天搞定且业务代码零改动，靠的就是这层隔离。ORM总会不断演进，架构上的这条原则不会变，这大概是我在这件事上最深的一点体会。