不限语言，你觉得最好用的框架和 ORM 是什么？

@bowencool #74
可以看一下 kysely-codegen ，直接从数据库把表结构以 TypeScript 类型定义的形式拉下来。

https://github.com/RobinBlomberg/kysely-codegen

@zpvip 你要讨论技术呢，我就给你认真讨论；扯别的那就算了
世界上排名 top 的大型互联网公司，别管国内 bbat 还是国外 FAANG ，主流语言都是静态语言
更别提规模大了之后，更多从动态语言转向静态语言

但这些都不是关键，对于大规模项目来说，那点脚本、语法糖带来的快捷，相对项目复杂度不值得一提
举个当前讨论的 orm 话题吧，对于一个大型一点的项目：
1. 出于统一入口需要，我需要把所有访问数据库的地方集中一处，不能散落各处，否则以后重估难道满世界翻代码？
2. 我需要以 lib 方式发布，以便共用和统一维护，最好以方法方式暴露
3. 需要比较直观，比如对应什么 sql 语句，是否合理走了索引等，审计和拦截等

ok ，所以看到了吗，所有的语言，orm 对我来说都是差不多的：
func listXXXByYYY(int yyy) XXXList {}
是的，很有 Java 的影子

要说业务开发，这些脚本语言，真别碰瓷 Spring Boot 以及背后的 DI 、DDD
连一点点挑战的可能都没有

Ruby on Rails

rust 的 sea-orm

odoo

@dragondove #96 我说的是“很丑”不是无法实现，如果你觉得他很“美”那就你说的对

@jchnxu #59

Drizzle, Kysely 和 上一代 ORM 的根本差别是，Drizzle, Kysely 希望在 TypeScript 尽可能舒服地写 SQL ，并提供 TypeScript 的一切功能（类型安全、智能提示）。
Prisma, TypeORM 设计一堆 Repository API: find, create, save... ；而 Drizzle, Kysely 选择完全还原 SQL: selece, insert...。
对于熟悉 SQL 的选手来说，使用 Drizzle, Kysely 读写数据库就像呼吸一样简单；而使用 Prisma, TypeORM 则需要反复查阅文档，不停学习 ORM 自创的 Repository API ，同时把握不住 Repository API 生成的 SQL 语句，对于复杂查询可能最终还是需要放弃 Repository API 使用 Raw SQL 。

<amp-youtube data-videoid="cTu9-C2rd-0" layout="responsive" width="480" height="270"></amp-youtube>

@hwdq0012 #6 sqlsugar 也不错

@K332 #78 第一个太亮眼了

@liuliuliuliu 你觉得 EF 的写法和我写的这两种有区别吗？基本连源代码字符串都差不多一样了。

JPA

写过 java 、kotlin 、c#、rust 、typescript ，使用过 30 款以上的 orm (mybatis, mybatis-plus, hibernate, jpa, ktorm, jooq, exposed, dapper, typeorm, prisma, sequelize 等等等等)，对我个人来说 typescript+drizzle 是目前的最优解。
因为近年来全面转向了 typescript ，nodejs 的全部 web 框架也都玩了一遍，我最喜欢 honojs ，elysiajs 也很好，不过不建议没有其他 web 框架经验的新手使用，因为在某些方面太过原始了，空白处都得从零编写。

@1wlinesperday #15 互联网业务，表层面不做联表，处理单表业务感觉挺好用的。

@cloudzhou #102

你举 FAANG 大都用静态语言这一点没错，(Facebook 用 PHP), 但那不是“因为静态语言一定优于动态语言”，而是看 CTO 或创始人用的是什么. 有点像 "今天世界上最先进的运输系统的设计，是由两千年前两匹战马的屁股宽度来决定的".

大公司的发展必然加入形形色色的人, 人多了, 组织架构也会带来更多的技术选择。但真正有几个公司能有成千上万的开发团队，中小公司开几个 VPS 的业务就在东施效颦, 这是完全没必要的.

Rails 在大公司真实案例多了去了：

- GitHub ，最初就是 Rails 单体，支撑过数亿级用户，直到今天核心依然是 Rails 。
- Shopify ，全球电商 SaaS 巨头，业务量之大足以秒杀国内绝大多数 Java 项目，照样用 Rails 单体架构搞定，直到后来业务实在复杂有少量拆分。
- Basecamp 就不说了，人家直接靠 Rails 吃饭，而且能养活一个公司二十年。现在任性直接写 Vanilla JS, 也不 uglify, 也不压缩, 不搞那些 KPI 业务.

你说 ORM 要 `集中入口`, `lib 化`, `方法暴露`，Rails 的 `ActiveRecord` 天然就做到了。

你想把 DB 访问收敛？`Service Object` + `Concern` 分层就行。

审计、拦截？ ActiveSupport callback 直接挂，全局生效。

查看 SQL ？ Rails 的日志本来就打印出来所有 sql ，development 模式下就能清清楚楚看到走没走索引。索引这种事都能拿到台面上讲? 我在跟大一新生聊天吗?

而你们那套 Java DI 、Spring Boot 的套路，那些引以为傲的单一功能原则，解耦, 很多情况下只是自 High ，说白了就是写一大堆配置和样板代码，把简单的问题复杂化, 最后一定会过度工程化, Rails 根本不需要 DI ，因为类加载直接就是常驻内存，controller 类里直接用 model 类和对象，少一大层 ceremony ，不香吗？当然我不排斥适度地解耦, 比如用 Service Object, PORO (Plain Old Ruby Object), 但不要有洁癖.

所谓“统一、可维护”，不是靠框架强迫出来的，而是靠团队 discipline 。Rails 的 Monolith 可以让你把精力放在业务逻辑本身，而不是在造一堆“防止程序员犯错”的样板层。复杂度应该放在业务里解决，而不是放在架构里自嗨。

Spring Boot 确实是大厂的选择，但那只是“企业级官僚组织”的选择, 你们继续沉迷在 接口、DTO 、Service 、Repository 、Factory 的样板代码的海洋吧。Rails 的选择是另一种道路：用更少的人力做出同样甚至更强大的系统。

@dragondove #110 我也感觉你写的和这个层主写的没啥区别，也没懂层主说他写的很美的点在哪里

@zpvip 有什么类似于 nextjs 之余 vercel 的 SAAS 可以快速体验的托管产品么？想尝试一下

首先排除 mybatis

@zpvip 在你发言之前，我就知道你要举 GitHub 、Shopify ，Basecamp 就不说了，是理念的领先，规模太小，GitHub 的话，用你自己的发言来反驳，岂不是刚刚好（而是看 CTO 或创始人用的是什么）
第一，Facebook 早多数用 Hack 系统，其中突出静态化检查等，Hack 可以说是运行 PHP 的环境，类似虚拟机

但凡，但凡，你去了解 GitHub 、Shopify 最近招聘，核心组件都在用 Go 等去重构

我评价一个语言的工业级，习惯是广泛使用的中间件
比如大数据下 Kafka Flink ，运维革命性 Docker K8s 等
很抱歉，没有找到 ror 的影子

@cloudzhou 😊，看看 ruby 这几年的 stack overflow 的排名状况就知道了，他还在吹 Rails 就不知道为啥了。

rails 的 active record 应该无人能出其右吧，用起来最简单，最傻瓜，最贴近自然语言。如果要复杂，也可以结合 Arel 一起用，可以做很复杂的查询。