[疑问] Dapper 在.Net 开发者中是否相对于 EF Core 更受欢迎
KomiSans · KomiSans · 2022-04-28 18:48:18 +08:00 · 2649 次点击这是一个创建于 939 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在为公司重构一个服务 专门做短信服务对接 负责发送短信和对短信的数据统计
原先的项目中用的是 EntityFrameWork Core
和 LinQ 集成写起来挺方便的 尤其是查询的时候
现在自己用 Dapper 来写 Orm 层的逻辑 主要是手写 SQL 加上 Dapper 对 IDbConnection 的方法扩展
个人感觉 Dapper 的最大优势就是比较自由 也是比较麻烦 需要自行编写 SQL 语句
原先的项目中用的是 EntityFrameWork Core
和 LinQ 集成写起来挺方便的 尤其是查询的时候
现在自己用 Dapper 来写 Orm 层的逻辑 主要是手写 SQL 加上 Dapper 对 IDbConnection 的方法扩展
个人感觉 Dapper 的最大优势就是比较自由 也是比较麻烦 需要自行编写 SQL 语句
 |
1
Chad0000 2022-04-28 18:53:20 +08:00
之前我是倾向于使用轻量级 ORM 就像你说的 Dapper （实际上我用的是 NPoco ），但现在我倾向于使用 EF 。手写 Sql 非常不利于重构。
|
 |
2
KomiSans OP @Chad0000 是的 EF Core 主要是在于和实体类耦合性比较大 Dapper 的话 自己写 SQL 的话 可能比较容易忽略某些错误
|
 |
3
GiantHard 2022-04-28 18:57:55 +08:00
个人的感觉是，EF 适合常规增删改查，Dapper 适合复杂报表查询。常规增删改查用 EF 生成出来的代码一半都没太大毛病，复杂查询用 Dapper 对 SQL 掌控性更高，方便排查问题与调优。
|
|
4
KomiSans OP @GiantHard 记得之前在的那家外包公司里的项目用的就是 EF 加上 LinQ 的写法查数据 Join 各种外键的 select 出来新的对象
|
 |
5
ration 2022-04-28 19:13:38 +08:00  1
1.使用 Dapper-Extensions ，可以减少使用 sql 。
2.复杂查询的话不建议使用 EF 各种 join 。 3.两种都可用，针对各种情况都有解决方案。 |
 |
6
thinkershare 2022-04-28 19:19:17 +08:00 1
正常直接使用 EFCore, 有需求的情况下直接在 Context 上直接调用原生 SQL, 我们的项目需要根据场景切换数据库(Oracle/MySql/SQL Server/MongoDB), 而且写 SQL 的时候都会使用 Repository 包一层, 按照实际引用的 Provider 做不同的适配, 如果要追求极致的性能, 我直接用 ADO.ENT 了, 另外简单的项目使用 LinqToDB. Framework 时代用 Dapper 比较多, Core 后基本没用过了
|
|
7
thinkershare 2022-04-28 19:20:12 +08:00
另外我们的项目 Query 和 Command 是分开的, 用了不同的数据库, 大部分时候并不需要复杂的 Join
|
 |
8
sun1991 2022-04-28 19:22:56 +08:00
Dapper 一直是我的最爱.
我认为 ORM 只对简单的数据操作有改善, 但是简单情况手写 sql 比 EF 之类的 ORM 也差不了多少. 复杂情况我情愿手写 sql. |
 |
9
sunhelter 2022-04-28 19:30:30 +08:00
从 Dapper 换成了 FreeSql ，既支持 Linq 也可以自己写 SQL
|
|
12
sun1991 2022-04-28 20:10:50 +08:00 1
@KomiSans
当然. 我是指*稍微*复杂一点的情况. ORM 与我的感觉是: 它像是一个能力不足的手下, 能在简单的 case 上帮我节省 20%的时间, 却在稍微复杂一点的 case 多花我 50%的时间. |
 |
13
billzhuang 2022-04-28 20:13:07 +08:00 via iPhone
小项目用 ef core
|
 |
14
NPC666 2022-04-28 20:20:43 +08:00
一直用 FreeSQL 的路过
|
 |
15
kergee 2022-04-28 20:39:15 +08:00
看成了 dapr🤔
|
 |
16
Rwing 2022-04-28 20:48:21 +08:00 2
呃，你可能有些误解，他俩不是非此即彼的选择，可以都选择啊。
其实 dapper 只是一个小的 db 辅助库，类似以前的 dbhelper 。 EF 才能叫做 ORM ，ORM 重点在于这个 R ，如何把关系映射出来，如何把纯粹的 db object 变成面向对象的对象。 |
 |
17
leeg810312 2022-04-28 22:18:30 +08:00
因为工作内容，业务系统只用 EF Core ，从工程管理角度代码里有很多 SQL 不利于维护，代码审核不容易发现问题，EF Core 发展到 6 ，绝大多数业务都没有必须用手写 SQL 才能实现的情况，很多轻量的聚合分析业务也可以用 LINQ 方式实现。我们有大数据业务，所以较大的数据分析业务我们直接用大数据方案了。
|
 |
18
beginor 2022-04-28 23:32:55 +08:00 via Android
为什么要二选一呢，两者配合不是更好？通用的相对简单的查询使用 linq 完成，复杂的涉及 SQL 特定函数的用 dapper 完成，这也需要讨论？
|
 |
20
bthulu 2022-04-29 08:14:49 +08:00
非常简单的针对明确的字段查询, 用 efcore 更快更方便, 稍微复杂一点涉及到动态字段的, 还是得原生 sql. 比如我一张表有 len1,len2,len3,...,len6 字段, 根据传进来的数字决定查询 len 几, 写 sql 的话, `"where len " + no`就可以了, 而 efcore 对此无能为力, 即便写成`.Where(e => {if (no == 1) return e.len1;if (no == 2) return e.len2;...})`, 也会报错无法查询.
|
 |
22
qW7bo2FbzbC0 2022-04-29 09:39:42 +08:00
NPoco + MySQLConnector ，dapper 试过，功能性不如 NPoco ，但是 NPoco 在高频请求的情况下，会出现连接管理问题。所以高频请求场景，我选择裸用 Driver
|
|
23
qW7bo2FbzbC0 2022-04-29 09:40:31 +08:00
EF 我感觉比较重，侵入性比较强，但是可以自动生成 DO 比较方便
|
 |
24
afirefish 2022-04-29 09:41:00 +08:00
换 FreeSql ，都有了。
|
 |
25
jjwjiang 2022-04-29 10:01:17 +08:00
复杂的场景无论如何最后一定是存储过程，EF 或者 Dapper 这种情况就是调 script ，没区别
简单的场景显然 EF 要好用得多，所以个人认为 Dapper 可以退出历史舞台了 |
 |
28
ClorisYe 2022-04-29 14:36:57 +08:00
ef 在做单个实例的增删改查很方便，做列表查询的时候我一般都用 dapper ，有一些复杂查询，直接在数据库查方便，可靠。
|
 |
29
quan01994 2022-04-29 15:46:09 +08:00
我一般用 linq2db ，也还可以 。
|
Select Language