×

.NET ORM 框架对比

独孤求败 独孤求败 发表于2026-06-25 09:53:06 浏览21 评论0

抢沙发发表评论

一、主流的八款 ORM 速览


框架
定位
开发模式
开源/厂商
最新版
EF Core
全功能重型 ORM
Code First / DB First
Microsoft 官方
9.x
Dapper
微型 ORM
手写 SQL + 对象映射
Stack Overflow
2.x
SqlSugar
国产全功能 ORM
Code First / DB First
国内社区
5.x
FreeSql
国产全功能 ORM
Code First / DB First
国内社区
3.x
NHibernate
全功能重型 ORM
XML/Fluent 映射
社区
5.x
Linq2DB
轻量 LINQ ORM
LINQ 转 SQL
社区
5.x
RepoDB
混合型 ORM
手写 SQL + 自动 CRUD
社区
2.x
PetaPoco
微型 ORM
手写 SQL + 动态生成
社区
6.x

以上为 2025~2026 年活跃维护的版本,NHibernate 虽老但在部分遗留项目中仍在用。

二、按核心维度横向拆开看


1. 性能:谁的 SQL 跑得快

工厂表动辄千万行,联表三四张,存储过程一大把。查询性能是硬指标。


框架
单表查询
联表查询
批量操作
内存占用
一句话评价
Dapper
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐(需扩展)
极低
快就一个字
RepoDB
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐
Dapper 的现代替代
Linq2DB
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐
LINQ 写出 Dapper 性能
FreeSql
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
国产里性能最强
SqlSugar
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
批量操作是招牌
EF Core
⭐⭐⭐
⭐⭐⭐
⭐⭐⭐
中高
追踪机制有开销
NHibernate
⭐⭐⭐
⭐⭐⭐⭐
⭐⭐
最慢
PetaPoco
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐
小巧够用


关键结论:Dapper 的简单查询比 EF Core 快 3~5 倍。但如果你的业务不追求极致性能,EF Core 的差距在现代硬件上几乎可以忽略。真正拉开差距的场景是批量操作——批量插入 10 万行,EF Core 逐条 SaveChanges 能跑好几分钟,FreeSql 和 SqlSugar 的 BulkInsert 秒级完成。

2. 开发效率:谁的开发体验更好

你一个人既要写后端又要写 SQL,开发效率是不能忽视的成本。


框架
上手难度
LINQ 支持
迁移工具
文档质量
EF Core
⭐⭐⭐⭐⭐
自带 Migration
官方文档满分
SqlSugar
⭐⭐⭐⭐⭐
自带
中文文档好
FreeSql
⭐⭐⭐⭐⭐
CodeFirst 自带
中文文档好
Dapper
无(需扩展)
简单即文档
NHibernate
⭐⭐⭐(HQL)
SchemaExport
英文为主
Linq2DB
⭐⭐⭐⭐⭐
T4 模板
英文,社区
RepoDB
⭐⭐⭐(Fluent)
英文,社区
PetaPoco
极低
简单即文档


你习惯 SQL Server + DDD,EF Core 的 Code First + Migration 在工厂项目里是好搭档——建表改表省掉大量手写 DDL。但如果你偏爱直接写 SQL,SqlSugar 和 FreeSql 的 LINQ 体验更接近 SQL 思维,不像 EF Core 有时会翻译出意外的东西。

3. SQL 控制力:

工厂信息化最绕不开的就是复杂报表、多表联查、存储过程。ORM 如果在这方面限制你,那就是给自己找麻烦。


框架
手写SQL
存储过程
视图
动态SQL
可混用ADO.NET
Dapper
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
可直接用
SqlSugar
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
可混用
FreeSql
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
可混用
RepoDB
⭐⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
可混用
EF Core
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐
可混用
Linq2DB
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐
可混用
NHibernate
⭐⭐⭐
⭐⭐⭐
⭐⭐⭐
⭐⭐
可混用
PetaPoco
⭐⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐
⭐⭐⭐
可混用


如果你习惯直接写 SQL 调优,Dapper 或 SqlSugar 更顺手。EF Core 的 LINQ 翻译有时不是你想要的 SQL,GroupBy + 复杂聚合的翻译尤其容易出问题,调优需要绕路。


三、工厂信息化四大场景的选型建议


场景一:MES / WMS 核心业务系统

推荐:EF Core + Dapper 混搭
日常 CRUD 用 EF Core(开发快、迁移方便);复杂报表 / 看板查询用 Dapper(SQL 可控、性能好)。你已有 SQL Server 2022,EF Core 8/9 对其支持非常成熟。


// 典型的混搭模式

public class ProductionOrderRepository

{

private readonly AppDbContext _db;

private readonly IDbConnection _conn;


// 简单 CRUD 走 EF Core

public async Task<Order?> GetById(int id)

=> await _db.Orders.FindAsync(id);


// 复杂报表走 Dapper

public async Task<List<DailyOutput>> GetDailyReport(DateTime date)

{

var sql = @"

SELECT LineCode, SUM(Qty) AS TotalQty,

AVG(CycleTime) AS AvgCycle

FROM ProductionRecords

WHERE WorkDate = @date

GROUP BY LineCode";

return (await _conn.QueryAsync<DailyOutput>(

sql, new { date })).ToList();

}

}

场景二:报表 / 看板 / 数据中台

推荐:Dapper 或 FreeSql
几乎全是手写 SQL 的复杂查询。FreeSql 的批量插入/更新比 EF Core 快得多,不需要 Migration、不需要变更追踪,轻装上阵。

场景三:对接金蝶云星空 / 第三方系统

推荐:SqlSugar
跨数据库支持好(MySql / SQLite / Oracle 都行),国产框架,对接国内 ERP 厂商踩坑少。SqlSugar 的 ISugarQueryable 写复杂 LINQ 比 EF 更接近 SQL 思维。

场景四:小工具 / 后台服务 / 命令行

推荐:PetaPoco 或 Dapper(Dapper.Contrib)
一个文件搞定,不依赖 DI 容器,启动快、内存少,非常适合 Windows Service 或定时任务。


图片

四、避坑指南:


以下都是我在工作中实际遇到过的坑:


易中框架
说明
N+1 查询
EF Core
Include 忘写或懒加载开着一查一大堆。工厂表关联多,上线前一定关掉懒加载。
追踪开销
EF Core
大批量查询记得加 .AsNoTracking(),不然 DbContext 越撑越大。
LINQ 翻译陷阱
EF Core
GroupBy + 复杂聚合的 SQL 翻译容易出问题,必要时降级到 FromSqlRaw
批量操作慢
EF Core
逐条 SaveChanges 插 10 万行要几分钟。用 BulkInsert 扩展或切 Dapper。
SQL 注入
Dapper
你写 SQL 就得自己防注入,务必参数化查询,别拼字符串。
Migration 冲突
EF Core
多人协作时 Migration 文件容易打架,工厂 IT 一般就一个人还好。
连接泄漏
全部
工厂系统跑几个月不重启,连接池不够用。确认 using 块覆盖完整。
仓储过度抽象
全部
别在 Dapper 上硬套 Repository + UnitOfWork 模式,那是给 EF Core 准备的。


五、最终的选型建议


 如果是你是做.NET的,我最直接的推荐是:主用 EF Core 8+,关键查询用 Dapper 兜底。


理由很清楚:

1. EF Core 的 Code First + Migration 让你不用手写建表脚本;

2. DDD 的聚合根、仓储模式在 EF Core 下天然契合;

3. SQL Server 的 JSON 列、全文索引等高阶特性,EF Core 8/9 都完整支持;

4. Dapper 作为补充,复杂报表不被 ORM 生成的 SQL 拖累;

5. 两个框架跟 SQL Server 的适配是 .NET 生态里最成熟的。


群贤毕至

访客