pseudo

@yzld2002 有的

@nicoljiang 我理解你遇到的问题是和 casdoor 相关的哈，和本帖无关。

此外，通过自己的场景推断某一个事物“简单”未免有些草率了。同样的逻辑可以推断出 Redis 也真的很简单，只是 KV 存储；前端也真的很简单，只是 DOM 操作； Machine learning 也真的很简单，只是给机器喂数据。

@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