@tangkikodo 非常感谢支持，文档确实肝了挺长时间的哈哈~ 之前就在 Github 上看到过你的分享，印象深刻，我们优化和解决问题的大方向是一致的，不过我确实把 orm.Schema 类从设计上直接和一个 ORM model 进行绑定了，目前支持了 Django 的 model ，未来也会支持 SQLAlchemy 等其他主流 ORM 库的 model ，我其实是实现了一个 ORM adaptor ，把常用的查询操作进行抽象，然后提供给 orm.Schema 调用的
https://github.com/utilmeta/utilmeta-py/tree/main/utilmeta/core/orm/backends

这样确实没有办法完美覆盖 100% 的情况，但也足以简单轻松地应对 95% 的 CRUD 情况了，因为大部分用户也只是在一些主流的 ORM 模型上编写 RESTful 接口，只要把普通字段，关系对象（外键，多对，级联），表达式（计数/求和/平均等）这些常用的字段进行（带一定配置参数的）标准化实现就可以适用于绝大多数场景了，剩下的复杂场景可以一事一议，让用户自行在函数中编写查询逻辑组合拼接，因为任何框架都不可能处理所有问题，所以肯定要留出这样的自由度

“如果视图数据需要对视图数据的中间， 或者底层的数据做些转换， 聚合计算之类的功能”：
因为 orm.Schema 的方法调用的数据也并非一定是最终的 API 返回结果，用户可以把它作为一个期望明确的 “标准化” 数据源，通过声明返回自己需要的任意结构的合法数据，之后可以在函数中或者 Schema 类的 @property 属性中进行聚合计算和后处理工作
https://docs.utilmeta.com/py/zh/guide/schema-query/#property

因为我是尽可能希望用 Python 的原生语法和规范来定义声明式语法，尽量减少专有概念或语法的引入，不太希望规定太多的参数或者方法名，也是希望能减轻用户的学习成本和心智负担，一眼就能看明白框架代码的含义和作用

当然这也只是我设计哲学上的拙见

祝好~ 望多交流

@tikazyq 感谢回复~ FastAPI 确实可以生成 OpenAPI 文档（这大概已经是现代 API 框架的标配了），但它自身对 RESTful CRUD 的能力支持有限，比较依赖生态，比如实现一个 Realworld 博客项目，UtilMeta 的实现（ https://github.com/utilmeta/utilmeta-py-realworld-example-app ）只需要 600+ 行代码，FastAPI 的实现（ https://github.com/nsidnev/fastapi-realworld-example-app ）需要 2500+ 行代码

所以我写 UtilMeta 一方面是方便现有的 Django, Flask 等项目进行平滑迁移，另一方面新项目也可以快速用它开发 RESTful 接口（目前全面支持 Django ORM 语法，后续也会支持其他主流 ORM 库），后面也会上线一个对应 API 管理平台（ https://utilmeta.com/zh ）实现 Python 后端项目的接口调试，日志查询等监控管理功能，所以会把 UtilMeta 做成了一个兼容 Python 主流框架的元框架

@metavoidx 看来 v2 的评论并不支持 markdown 也没法编辑，Github 链接在 https://github.com/utilmeta/utilmeta-py