VIBE CODING 时代,应用开发是否应该使用 ORM ?

查看 307|回复 29
Lockroach   
不用的话,修改/重构数据库相关的地方,会很痛苦吧。
ORM 能防呆,编译时就能提前发现问题,不用就亏了。
RAW SQL 也是让 ORM 框架用强大的编程语法在编译时生成静态 SQL ,同样享受健壮性。
LLM 确定性太差了,和人一样,工程化手段还是得上。
iDelicious   
rawsql 自己按功能稍微封装一下
数据库迁移靠 flyway 这类东西
验证靠单元测试,而且用 testcontainer 这种工具做尽量真实的测试,刚好配合 flyway 。
把业务层拍平到一层,不单独写数据处理层。
这样 AI 直接靠 SQL 判断业务,而不是靠 ORM 的方法名,不需要去推断 ORM 展开的 SQL
spike0100   
https://mkennedy.codes/posts/raw-dc-the-orm-pattern-of-2026/
rawsql + dataclass 也不错
fj24911   
学习和使用 orm 其实收益不是很大,每个语言生态都有 orm ,难道每个都学一遍吗。用 rawsql 可以抹平不同的语言鸿沟,ai 也更好修改。
chendy   
Vibe Coding 的时代,开发是否应该直接使用汇编语言?
james122333   
现在 ai 想怎么写就怎么写,只要最终结果是我要的,我已经不太在乎是怎么实现的了。感觉人快废了。
msg7086   
如果对 orm 框架不熟悉或者基于减少程度调用链路的考虑,可以让 ai 封装一个简单的 orm ;
xiaomushen   
Vibe Coding 的时代,是否应该使用穿孔纸带
cc9910   
第一 能的话尽量不要使用 sql 语法真的很烂 orm 目的是为了减少以上麻烦
第二 不能的话尽量自己写自己的 orm 实现起来并不困难 也少了一堆小坑需要踩 还有 db 栏位与 type 栏位不同名称是烂设计 一致性非常差 虽然我也实现过这样的
第三 rawsql 和 orm 哪个好我觉得除了长 sql 以外差不多 orm 只是再套一层省点拼写错误 拼写参数的麻烦 长 sql 再套层会比较好维护 至于注入倒是还好 毕竟预编译再输入参数是 db 本来就有的功能 与你是否使用 orm 无关 顶多再弄个正则也就完事了
放弃过渡设计的东西不用浪费时间
spike0100   
不用 ORM 的结果就是 AI 帮你写半个类似 ORM 的东西勉强用着。既然勉强用着为什么不直接用成品 ORM 。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部