loocor
commented
2 years ago 其实说白了，是一个相对完整的代码生成能力。golang 相关的 gva 或者 go-zero 都提供了类似/相关的功能。
不同的地方在于，gva 将生成的能力建立在 gva能跑起来的基础上，无法从零开始，一定程度上也被图形界面“绑架”难以进一步扩展。 而 go-zero 采用了自定义的 api 格式以及成熟的 proto 格式，增加了维护成本、学习成本及开发成本，同时也降低了整个流程的流畅性。作为对比，go-kratos使用一份 proto 文件生成 api 及 rpc 代码，综合来看更合理。
但 proto 文件的信息密度似乎比较低，而且字段的1、2、3序列确实不够优雅有些莫名其妙。因此：
就使用 golang 文件定义源头是最合理的，通过熟悉的 golang 语法定义结构体，以此生成 ddl （或直接创建数据表）、controler、service 是更顺畅简便的。
zcyc
现在 gf 推荐的代码组织方式已经非常规范，新增一个功能/应用的流程基本遵循：
1、定义数据库表
按照一般要求定义实体字段，如 User 的 Name、Gender、Age、Mobile 等，按照 gf 时间管理特性定义 createdAt、updatedAt 等字段。而为了区分模块组，表名有组名和实体名构成，如 SystemUser。
定义好表之后，执行 gf gen dao 生成相关文件。
2、定义规范路由
参照生成的 entity.SystemUser 文件，使用 cv 大法定义规范路由结构体。
基本 req / resp 成对出现，名称类似
UserAddReq / UserAddRes; UserGetReq / UserGetRes;UserEditReq / UserEditRes; UserDeleteReq / UserDeleteRes; UserListReq / UseListRes，都是由 模块名称、请求动作 构成，有清晰明确的规则。结构体的实体字段名称，与数据库字段名一一对应（最佳状态是直接匿名嵌入
entity.User），结构体标签中 p 默认为字段名称的首字母小写驼峰命名。针对不同的请求动作，也有相对确定的模式，比如 UserListReq 包含分页参数、对应结构体字段的查询参数组、参数组与或关系标记。而 UserListRes 中除标准的 code、message外，data 中默认节点是名为 list 的
[]User数据。因此理论上，类似
gf gen dao的功能，是可以具体 ddl 生成规范路由脚手架代码的。3、定义 controller
这个环节纯粹是 cv 操作，除特别情况外几乎就是引入规范路由作为参数传递到下一层的 service 部分。一般情况下与规范路由的 Add、Get、Edit、Delete、List 完全对应，因此也是可以自动生成的。
4、定义Service
同上，针对 crud 外加一个 list，可基于 entity 自动生成 Add、Update、List 部分的初始代码，约定 pkey 为 id 字段的情况下，可生成 Get、Delete 部分的代码。
概括来说，以数据库为源头生成符合 gf 实践规则的初始代码，已经可以满足大部分需求。如在此基础上控制好重复执行生成操作代码的保留与覆盖规则，类似 Django 等框架提供的迁移功能，那就NB大发了