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

[KomiSans]

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

个人感觉 Dapper 的最大优势就是比较自由 也是比较麻烦 需要自行编写 SQL 语句

[ktqFDx9m2Bvfq3y4]

之前我是倾向于使用轻量级 ORM 就像你说的 Dapper （实际上我用的是 NPoco ），但现在我倾向于使用 EF 。手写 Sql 非常不利于重构。

[KomiSans]

@Chad0000 是的 EF Core 主要是在于和实体类耦合性比较大 Dapper 的话 自己写 SQL 的话 可能比较容易忽略某些错误

[GiantHard]

个人的感觉是，EF 适合常规增删改查，Dapper 适合复杂报表查询。常规增删改查用 EF 生成出来的代码一半都没太大毛病，复杂查询用 Dapper 对 SQL 掌控性更高，方便排查问题与调优。

[KomiSans]

@GiantHard 记得之前在的那家外包公司里的项目用的就是 EF 加上 LinQ 的写法查数据 Join 各种外键的 select 出来新的对象

[ration]

1.使用 Dapper-Extensions ，可以减少使用 sql 。
2.复杂查询的话不建议使用 EF 各种 join 。
3.两种都可用，针对各种情况都有解决方案。

[thinkershare]

正常直接使用 EFCore, 有需求的情况下直接在 Context 上直接调用原生 SQL, 我们的项目需要根据场景切换数据库(Oracle/MySql/SQL Server/MongoDB), 而且写 SQL 的时候都会使用 Repository 包一层, 按照实际引用的 Provider 做不同的适配, 如果要追求极致的性能, 我直接用 ADO.ENT 了, 另外简单的项目使用 LinqToDB. Framework 时代用 Dapper 比较多, Core 后基本没用过了

[thinkershare]

另外我们的项目 Query 和 Command 是分开的, 用了不同的数据库, 大部分时候并不需要复杂的 Join

[sun1991]

Dapper 一直是我的最爱.
我认为 ORM 只对简单的数据操作有改善, 但是简单情况手写 sql 比 EF 之类的 ORM 也差不了多少.
复杂情况我情愿手写 sql.

[sunhelter]

从 Dapper 换成了 FreeSql ，既支持 Linq 也可以自己写 SQL

[KomiSans]

@sun1991 em 这个时候最好还是写个存储过程吧.

[KomiSans]

@sunhelter 好 我去看看 之前听说过 SqlSugar 的

[sun1991]

@KomiSans
当然. 我是指*稍微*复杂一点的情况.

ORM 与我的感觉是: 它像是一个能力不足的手下, 能在简单的 case 上帮我节省 20%的时间, 却在稍微复杂一点的 case 多花我 50%的时间.

[billzhuang]

小项目用 ef core

[NPC666]

一直用 FreeSQL 的路过

[kergee]

看成了 dapr🤔

[Rwing]

呃，你可能有些误解，他俩不是非此即彼的选择，可以都选择啊。
其实 dapper 只是一个小的 db 辅助库，类似以前的 dbhelper 。
EF 才能叫做 ORM ，ORM 重点在于这个 R ，如何把关系映射出来，如何把纯粹的 db object 变成面向对象的对象。

[leeg810312]

因为工作内容，业务系统只用 EF Core ，从工程管理角度代码里有很多 SQL 不利于维护，代码审核不容易发现问题，EF Core 发展到 6 ，绝大多数业务都没有必须用手写 SQL 才能实现的情况，很多轻量的聚合分析业务也可以用 LINQ 方式实现。我们有大数据业务，所以较大的数据分析业务我们直接用大数据方案了。

[beginor]

为什么要二选一呢，两者配合不是更好？通用的相对简单的查询使用 linq 完成，复杂的涉及 SQL 特定函数的用 dapper 完成，这也需要讨论？

[KomiSans]

@beginor 并不是捧一个踩一个的那种意思啦

[bthulu]

非常简单的针对明确的字段查询, 用 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;...})`, 也会报错无法查询.

[KomiSans]

@bthulu 对 如果只是写 LinQ 有时候很难查到哪一个地方出错

[qW7bo2FbzbC0]

NPoco + MySQLConnector ，dapper 试过，功能性不如 NPoco ，但是 NPoco 在高频请求的情况下，会出现连接管理问题。所以高频请求场景，我选择裸用 Driver

[qW7bo2FbzbC0]

EF 我感觉比较重，侵入性比较强，但是可以自动生成 DO 比较方便

[afirefish]

换 FreeSql ，都有了。

[jjwjiang]

复杂的场景无论如何最后一定是存储过程，EF 或者 Dapper 这种情况就是调 script ，没区别

简单的场景显然 EF 要好用得多，所以个人认为 Dapper 可以退出历史舞台了

[KomiSans]

@jjwjiang 我记得当时在 Infosys 的时候大部分业务逻辑实现就是各种各样的存储过程 挺真实的

[jjwjiang]

@bthulu 这不是 EF 的范畴和问题，用表达式树可以很简单的解决这个问题

[ClorisYe]

ef 在做单个实例的增删改查很方便，做列表查询的时候我一般都用 dapper ，有一些复杂查询，直接在数据库查方便，可靠。

[quan01994]

我一般用 linq2db ，也还可以 。