VIBE CODING 时代，应用开发是否应该使用 ORM ？

[Leon6868]

我认为 ORM 是有存在价值的，原因如下：

• ORM 提供了标准的数据库迁移脚手架
• 能在一定程度上规避 SQL 注入攻击（不知道现在大模型写的代码是否容易出现这些漏洞）
• 提供标准的数据库操作方法
• 能通过 LSP 将数据库操作纳入大模型调试闭环
• 高性能的操作也可以手写 SQL ，有一定的灵活性

大家在开发中是否用 ORM 呢？用的都是哪些 ORM ？

[cheng6563]

rawsql 自己按功能稍微封装一下
数据库迁移靠 flyway 这类东西
验证靠单元测试，而且用 testcontainer 这种工具做尽量真实的测试，刚好配合 flyway 。
把业务层拍平到一层，不单独写数据处理层。
这样 AI 直接靠 SQL 判断业务，而不是靠 ORM 的方法名，不需要去推断 ORM 展开的 SQL

[UB]

https://mkennedy.codes/posts/raw-dc-the-orm-pattern-of-2026/

rawsql + dataclass 也不错

[Lockroach]

学习和使用 orm 其实收益不是很大，每个语言生态都有 orm ，难道每个都学一遍吗。用 rawsql 可以抹平不同的语言鸿沟，ai 也更好修改。

[iDelicious]

Vibe Coding 的时代，开发是否应该直接使用汇编语言？

[spike0100]

现在 ai 想怎么写就怎么写，只要最终结果是我要的，我已经不太在乎是怎么实现的了。感觉人快废了。

[fj24911]

如果对 orm 框架不熟悉或者基于减少程度调用链路的考虑，可以让 ai 封装一个简单的 orm ；

[chendy]

Vibe Coding 的时代，是否应该使用穿孔纸带

[james122333]

第一 能的话尽量不要使用 sql 语法真的很烂 orm 目的是为了减少以上麻烦
第二 不能的话尽量自己写自己的 orm 实现起来并不困难 也少了一堆小坑需要踩 还有 db 栏位与 type 栏位不同名称是烂设计 一致性非常差 虽然我也实现过这样的
第三 rawsql 和 orm 哪个好我觉得除了长 sql 以外差不多 orm 只是再套一层省点拼写错误 拼写参数的麻烦 长 sql 再套层会比较好维护 至于注入倒是还好 毕竟预编译再输入参数是 db 本来就有的功能 与你是否使用 orm 无关 顶多再弄个正则也就完事了

放弃过渡设计的东西不用浪费时间

[msg7086]

不用 ORM 的结果就是 AI 帮你写半个类似 ORM 的东西勉强用着。既然勉强用着为什么不直接用成品 ORM 。

[woodyang]

要用的吧

[james122333]

@msg7086

这根本不用 ai
要做的比流行框架运行效率高也很容易
配置简单好开发才是王道
那些框架多弄的 你不会感觉出来有优势的

[Mantext1989]

用呗，手写 SQL 可读性怎么办呢

[xmt328]

ORM 有安全保证，你能保证 AI 写的每一句 SQL 都没问题么