pseudo

@reorx 谢谢，好主意。我先在项目里实践看看，后续看能不能拓展一下

@Aloento 不好说咱就别说？

@reorx #1 谢谢。我觉得你说的很有道理，但我们 stay with native SQL 其实就是想利用好 DB 的特性。如果 createModel 变成了 ORM 感觉就有点重复造轮子了？

准备先在真实项目里实践一下试试效果，不错的话我再写一篇文章展开一下这个 approach

@jchnxu 不太熟悉 class + decorator ，简单看了一下代码感觉 class prop 本身类型定义可能无法避免，可能可以从 decorator 下手。还有 class level decorator 可能也可以尝试。
感觉主要原因还是两种不同的对数据模型处理的方向，所以并不能很顺利地结合。我们项目里 SSOT 是 SQL ，zod 定义都是生成的，维护起来稍微简单点。

@jchnxu #13 或者直接用 zod 之类的库当作类型定义的 SSOT 是不是也是个办法？个人比较喜欢 native + fp 的路子，代码比较清晰。ORM 加了一层抽象会屏蔽数据库的一些特性，有利有弊吧。

@codehz #8 是的，我很早之前用过装饰器的库（ mobx ）并尝试过写装饰器，感觉像个黑盒，并且和 FP 的理念不一致，如果要使用就得一条路走到黑。加上一直处于不稳定状态，之后就完全不用了。
@devtiange #9 谢谢支持

@amlee #6 谢谢，我的创业项目就是做用户系统的： https://logto.io

@amlee #3 嗯，看上去是有点类似，之后可以做到通过类型定义 / SQL 直接生成 CRUD 接口。和 Hasura 有点像，但 stick with REST ，其余与框架无关
@debuggerx #4 赞 👍 向你学习

@wdhwg001 哈哈，我和你正好相反，看到 decorator 就放弃了