V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
KomiSans
V2EX  ›  程序员

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

  •  
  •   KomiSans ·
    KomiSans · 2022-04-28 18:48:18 +08:00 · 2370 次点击
    这是一个创建于 700 天前的主题,其中的信息可能已经有所发展或是发生改变。
    最近在为公司重构一个服务 专门做短信服务对接 负责发送短信和对短信的数据统计
    原先的项目中用的是 EntityFrameWork Core
    和 LinQ 集成写起来挺方便的 尤其是查询的时候
    现在自己用 Dapper 来写 Orm 层的逻辑 主要是手写 SQL 加上 Dapper 对 IDbConnection 的方法扩展

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

    ORM 与我的感觉是: 它像是一个能力不足的手下, 能在简单的 case 上帮我节省 20%的时间, 却在稍微复杂一点的 case 多花我 50%的时间.
    billzhuang
        13
    billzhuang  
       2022-04-28 20:13:07 +08:00 via iPhone
    小项目用 ef core
    NPC666
        14
    NPC666  
       2022-04-28 20:20:43 +08:00
    一直用 FreeSQL 的路过
    kergee
        15
    kergee  
       2022-04-28 20:39:15 +08:00
    看成了 dapr🤔
    Rwing
        16
    Rwing  
       2022-04-28 20:48:21 +08:00   ❤️ 2
    呃,你可能有些误解,他俩不是非此即彼的选择,可以都选择啊。
    其实 dapper 只是一个小的 db 辅助库,类似以前的 dbhelper 。
    EF 才能叫做 ORM ,ORM 重点在于这个 R ,如何把关系映射出来,如何把纯粹的 db object 变成面向对象的对象。
    leeg810312
        17
    leeg810312  
       2022-04-28 22:18:30 +08:00
    因为工作内容,业务系统只用 EF Core ,从工程管理角度代码里有很多 SQL 不利于维护,代码审核不容易发现问题,EF Core 发展到 6 ,绝大多数业务都没有必须用手写 SQL 才能实现的情况,很多轻量的聚合分析业务也可以用 LINQ 方式实现。我们有大数据业务,所以较大的数据分析业务我们直接用大数据方案了。
    beginor
        18
    beginor  
       2022-04-28 23:32:55 +08:00 via Android
    为什么要二选一呢,两者配合不是更好?通用的相对简单的查询使用 linq 完成,复杂的涉及 SQL 特定函数的用 dapper 完成,这也需要讨论?
    KomiSans
        19
    KomiSans  
    OP
       2022-04-29 08:14:36 +08:00 via Android
    @beginor 并不是捧一个踩一个的那种意思啦
    bthulu
        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;...})`, 也会报错无法查询.
    KomiSans
        21
    KomiSans  
    OP
       2022-04-29 09:32:45 +08:00
    @bthulu 对 如果只是写 LinQ 有时候很难查到哪一个地方出错
    qW7bo2FbzbC0
        22
    qW7bo2FbzbC0  
       2022-04-29 09:39:42 +08:00
    NPoco + MySQLConnector ,dapper 试过,功能性不如 NPoco ,但是 NPoco 在高频请求的情况下,会出现连接管理问题。所以高频请求场景,我选择裸用 Driver
    qW7bo2FbzbC0
        23
    qW7bo2FbzbC0  
       2022-04-29 09:40:31 +08:00
    EF 我感觉比较重,侵入性比较强,但是可以自动生成 DO 比较方便
    afirefish
        24
    afirefish  
       2022-04-29 09:41:00 +08:00
    换 FreeSql ,都有了。
    jjwjiang
        25
    jjwjiang  
       2022-04-29 10:01:17 +08:00
    复杂的场景无论如何最后一定是存储过程,EF 或者 Dapper 这种情况就是调 script ,没区别

    简单的场景显然 EF 要好用得多,所以个人认为 Dapper 可以退出历史舞台了
    KomiSans
        26
    KomiSans  
    OP
       2022-04-29 10:05:02 +08:00
    @jjwjiang 我记得当时在 Infosys 的时候大部分业务逻辑实现就是各种各样的存储过程 挺真实的
    jjwjiang
        27
    jjwjiang  
       2022-04-29 10:13:05 +08:00
    @bthulu 这不是 EF 的范畴和问题,用表达式树可以很简单的解决这个问题
    ClorisYe
        28
    ClorisYe  
       2022-04-29 14:36:57 +08:00
    ef 在做单个实例的增删改查很方便,做列表查询的时候我一般都用 dapper ,有一些复杂查询,直接在数据库查方便,可靠。
    quan01994
        29
    quan01994  
       2022-04-29 15:46:09 +08:00
    我一般用 linq2db ,也还可以 。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3310 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 13:33 · PVG 21:33 · LAX 06:33 · JFK 09:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.