[疑问] Dapper 在.Net 开发者中是否相对于 EF Core 更受欢迎

2022-04-28 18:48:18 +08:00
 KomiSans
最近在为公司重构一个服务 专门做短信服务对接 负责发送短信和对短信的数据统计
原先的项目中用的是 EntityFrameWork Core
和 LinQ 集成写起来挺方便的 尤其是查询的时候
现在自己用 Dapper 来写 Orm 层的逻辑 主要是手写 SQL 加上 Dapper 对 IDbConnection 的方法扩展

个人感觉 Dapper 的最大优势就是比较自由 也是比较麻烦 需要自行编写 SQL 语句
2418 次点击
所在节点    程序员
29 条回复
Chad0000
2022-04-28 18:53:20 +08:00
之前我是倾向于使用轻量级 ORM 就像你说的 Dapper (实际上我用的是 NPoco ),但现在我倾向于使用 EF 。手写 Sql 非常不利于重构。
KomiSans
2022-04-28 18:56:56 +08:00
@Chad0000 是的 EF Core 主要是在于和实体类耦合性比较大 Dapper 的话 自己写 SQL 的话 可能比较容易忽略某些错误
GiantHard
2022-04-28 18:57:55 +08:00
个人的感觉是,EF 适合常规增删改查,Dapper 适合复杂报表查询。常规增删改查用 EF 生成出来的代码一半都没太大毛病,复杂查询用 Dapper 对 SQL 掌控性更高,方便排查问题与调优。
KomiSans
2022-04-28 19:00:02 +08:00
@GiantHard 记得之前在的那家外包公司里的项目用的就是 EF 加上 LinQ 的写法查数据 Join 各种外键的 select 出来新的对象
ration
2022-04-28 19:13:38 +08:00
1.使用 Dapper-Extensions ,可以减少使用 sql 。
2.复杂查询的话不建议使用 EF 各种 join 。
3.两种都可用,针对各种情况都有解决方案。
thinkershare
2022-04-28 19:19:17 +08:00
正常直接使用 EFCore, 有需求的情况下直接在 Context 上直接调用原生 SQL, 我们的项目需要根据场景切换数据库(Oracle/MySql/SQL Server/MongoDB), 而且写 SQL 的时候都会使用 Repository 包一层, 按照实际引用的 Provider 做不同的适配, 如果要追求极致的性能, 我直接用 ADO.ENT 了, 另外简单的项目使用 LinqToDB. Framework 时代用 Dapper 比较多, Core 后基本没用过了
thinkershare
2022-04-28 19:20:12 +08:00
另外我们的项目 Query 和 Command 是分开的, 用了不同的数据库, 大部分时候并不需要复杂的 Join
sun1991
2022-04-28 19:22:56 +08:00
Dapper 一直是我的最爱.
我认为 ORM 只对简单的数据操作有改善, 但是简单情况手写 sql 比 EF 之类的 ORM 也差不了多少.
复杂情况我情愿手写 sql.
sunhelter
2022-04-28 19:30:30 +08:00
从 Dapper 换成了 FreeSql ,既支持 Linq 也可以自己写 SQL
KomiSans
2022-04-28 19:45:14 +08:00
@sun1991 em 这个时候最好还是写个存储过程吧.
KomiSans
2022-04-28 19:46:39 +08:00
@sunhelter 好 我去看看 之前听说过 SqlSugar 的
sun1991
2022-04-28 20:10:50 +08:00
@KomiSans
当然. 我是指*稍微*复杂一点的情况.

ORM 与我的感觉是: 它像是一个能力不足的手下, 能在简单的 case 上帮我节省 20%的时间, 却在稍微复杂一点的 case 多花我 50%的时间.
billzhuang
2022-04-28 20:13:07 +08:00
小项目用 ef core
NPC666
2022-04-28 20:20:43 +08:00
一直用 FreeSQL 的路过
kergee
2022-04-28 20:39:15 +08:00
看成了 dapr🤔
Rwing
2022-04-28 20:48:21 +08:00
呃,你可能有些误解,他俩不是非此即彼的选择,可以都选择啊。
其实 dapper 只是一个小的 db 辅助库,类似以前的 dbhelper 。
EF 才能叫做 ORM ,ORM 重点在于这个 R ,如何把关系映射出来,如何把纯粹的 db object 变成面向对象的对象。
leeg810312
2022-04-28 22:18:30 +08:00
因为工作内容,业务系统只用 EF Core ,从工程管理角度代码里有很多 SQL 不利于维护,代码审核不容易发现问题,EF Core 发展到 6 ,绝大多数业务都没有必须用手写 SQL 才能实现的情况,很多轻量的聚合分析业务也可以用 LINQ 方式实现。我们有大数据业务,所以较大的数据分析业务我们直接用大数据方案了。
beginor
2022-04-28 23:32:55 +08:00
为什么要二选一呢,两者配合不是更好?通用的相对简单的查询使用 linq 完成,复杂的涉及 SQL 特定函数的用 dapper 完成,这也需要讨论?
KomiSans
2022-04-29 08:14:36 +08:00
@beginor 并不是捧一个踩一个的那种意思啦
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;...})`, 也会报错无法查询.

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/849876

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX