大家喜欢用 ORM 还是直接写 SQL

[gitrebase]

OP 主要用的 Java 和 Go ，但是感觉这俩主流语言的 ORM 框架（ JPA 、GORM ）都不如 C#、Python 的 ORM 好用（ JOOQ 、ent 、XORM 感觉国内用的还是有点少），而 SQL / SQL builder （ JdbcTemplate 、sqlx ）在动态条件查询时需要在代码里拼 SQL 字符串也有点🥚疼

其实就是最近在玩 Spring 新出的 JdbcClient （ JdbcTemplate 的封装版），感觉在 Java 有多行字符串后，在 Java 代码里写 SQL 完全不是什么问题，而且也不用使用难用的 XML 去定义 resultMap （直接在 Java 里定义 record 或者 class 然后用构造器就可以了）

public record User(Long id, String name, Integer sex) {
}

@GetMapping("/users/in")
public Iterable<User> listInIds(@RequestParam List<Integer> ids) {
    return jdbcClient.sql("""
            SELECT *
            FROM `user`
            WHERE `id` IN (:ids)
            """)
            .param("ids", ids)
            .query(User.class)
            .list();
}

但是在碰到动态条件的 where 语句的时候，在 Java 代码里手搓 SQL 看着也很让人头大……这时候 MyBatis 提供的 dynamic SQL 就很好用了

但真的不喜欢 XML……

MyBatis-Plus 也了解过，但说不上来为什么，总是感觉不太喜欢这个库……

[hefish]

我一直喜欢写规范的 SQL ，奈何前些年 ORM 更流行。

[programMrxu]

比较喜欢 orm ，

[ashuai]

投 SQL92 一票。
小项目怎么顺手怎么来。
大项目特别是有性能要求的，ORM hold 不 hold 得住先？

[potatowish]

首先，MyBatis 配置开启驼峰命名映射时，也不用写 resultMap ，在 MBP 中也是默认开启的。

个人的话简单项目用 JPA ，复杂项目用 MBP 。不讨厌 XML ，更喜欢原生的 SQL 。

[liuhan907]

我个人更喜欢 ORM ，但我是写 C# 的。

[xiaoxinTOm]

有些比较复杂的 sql 要写简直要死，我 sql 写不好，有些需求完全没有思虑，现在用 gpt 写

[chendy]

都用，简单的 orm ，复杂的 sql

[just1]

喜欢手写 sql ，但是代码里如果有变量还是 orm 。python 有啥好用的 orm

[XCFOX]

据我观察，大部分 Java 和 Go 开发者对 ORM 无感甚至讨厌 ORM ；而大部分 C#、Node.js 、Ruby 开发者喜欢用 ORM 。
原因其实很简单，C# 的 EF Core 、Node.js 的 Prisma, MikroOrm 、Ruby 的 ActiveRecord 很好用。

一款好的 ORM 应该尽可能提供该语言原生的写法，提供完善的类型安全、提供灵活的 Query Builder 以应对尽量多的 SQL 语法。

Java/Go 生态内缺少用起来顺手的 ORM 。要是 Java 有 EF Core 、Go 有 Prisma ，我相信所有人都会喜欢 ORM 。

[lilichen]

C#, ORM

[taotaodaddy]

@just1 我用 python 的 peewee,感觉还可以

[QlanQ]

orm 好用的多，特别是那种关联关系
手写 sql ，如果在后续需求中，需要加入软删除，是不是每个 sql 都要检查，包括链表查询
还有一对多和多对多，后续调整的时候，如果手写这种 sql ，是不是差不多项目要重构了？如果用 orm 的话，就简单很多了
有说如果 sql 很复杂，orm 的性能跟不上，可能我代码写的少了，我并没有遇到 sql 很复杂的情况，如果 sql 很复杂多链表的情况，一般都是 分成多个简单的 sql ，然后用程序处理的吧

[xuld]

这是我设计的内置 sql 的语法：
return db.queryAll(User -> u where ids.contains(u.id) orderby u.createBy desc select u.id, u.name)

[gam2046]

不确定我理解的对不对。ORM 主要解决的是编程语言数据类型与数据库类型不一致，进而实现了，切换数据库而不用修改代码的结果。

但是这种结果在现实条件里太少了，没有人会无聊了换数据库玩。

那么回到语言类型与数据库类型不一致的问题上来，其实自己解决也并没有多麻烦，特别是现在许多数据库支持一些非简单类型的数据，（例如 JSON/Blob 等等），对于这些类型，ORM 反而支持的不太好，还不如自己手写。

所以现阶段来看，我粗浅的认为，ORM 并不是必须的（也就是说并没有解决什么实质上的问题），依据个人习惯来好了。手搓 SQL 更能控制 SQL 语句的质量与规模。我想没几个项目从头至尾都是简单的单表查询吧，多表查询，ORM 生成的语句质量，一般也就是个中规中矩，能用的水平。

[jjww]

c#, 看场景吧.
一般情况下 EF Core 搞定.
二般情况比如用 timescaledb 的时候就 dbup + 手写迁移文件.

[seth19960929]

肯定 ORM ， 我还是无法理解动态 SQL 怎么用原生好写？难不成自己封装一个类优雅的组装， 结果只有自己会用，到头来就是不肯用开源的呗？

[StoneHuLu]

我写 c#，我用 freeSql 的，ef 我觉得太重了，freeSql 主要是比较灵活，想 orm 就 orm ，想 sql 就 sql ，里面直接一个 ado 拿出来，想咋用就咋用，配置也很简单，各种 aop 功能方便调试

[changdy]

@gam2046 现在数据库之间的差异 太大了.已经不是 orm 能弥补得了.

对于日常两三张表 join 以上的情况 只有手写 sql.
如果日常不 join 表 那肯定可以用 orm.

[sephiroka]

肯定是都用啊

[Features]

PHP 的 ORM 天下第一