docs/cli/gen-ctrl

[giscus[bot]]

docs/cli/gen-ctrl

该功能特性从 v2.5 版本开始提供。该命令目前仅支持 HTTP 接口开发， GRPC 部分请参考 gen pb 命令。未来会考虑 HTTP 及 GRPC 统一使用该命令生成控制器及 SDK 源代码。

https://goframe.org/docs/cli/gen-ctrl

[shayuevil]

为什么放我使用命令的时候，老是提示不对呢，报错是这个：expected 'package' , found b (and 186 more errors)呢

[gqcn]

你看下报错的源码文件呢。

[Mengxing2]

请问大佬VSCode有自动 gf gen 唱跳rap🏀 的配置文件吗？

[gqcn]

没有的，不过欢迎大家一起来共建。

[yhuaao]

响应应该是一个公共的泛型结构体。这种模式就得为每一个接口，定义一个响应结构体。没必要吧。 ctrl模板限制太死了。基本上没用

type IHelloV1 interface {
	Hello(ctx context.Context, req *v1.HelloReq) (res *api.Response[any], err error)
}

Response[any], 这样不好吗？ 生成的代码直接把我定义的泛型给覆盖了

[gqcn]

你好，业务的API接口中不需要使用泛型来满足公共返回结构体的需求，可以参考这篇文档 https://goframe.org/quick/common-response

[apefuu]

请问有没有这种模式，比如我api定义了system/admin/role/v1 和 system/admin/permission/v1 ，然后在Controller里生成对应的目录system/admin/role system/admin/permission 。目前的话会直接生成一个system目录，然后所有的go文件挤在一个目录了。这个对于架构上而言有点受不了，请解答，感谢

[apefuu]

事实上我也发现了一个规律，想要分目录，得在api/下就分，但是我想就只分几个大类，然后在大类目录下根据子目录生成Controller目录

[gqcn]

@apefuu 我们通常推荐使用大仓来管理代码，即前后端是不同的binary，源代码是相对独立的。参考文档：https://goframe.org.cn/docs/design/project-mono-repo

[apefuu]

万分感谢，微服务的通讯上，我能采用nacos或r-nacos+dubbo的tri协议去平替gf的微服务通讯模式吗，dubbo有go的SDK

[apefuu]

关于API SDK的具体讲解、使用场景和最佳实践有对应的文档吗，我好像没找到

[gqcn]

由于比较简单，所以API SDK这块没有文档介绍，你可以通过参数生成后查看源码就知道怎么用了。

[apefuu]

万分感谢，微服务的通讯上，我能采用nacos或r-nacos+dubbo的tri协议去平替gf的微服务通讯模式吗，dubbo有go的SDK

[gqcn]

Golang的话推荐使用grpc来进行服务间通信，goframe提供的社区微服务组件grpcx也是基于该协议。如果使用dubbo的话也是可以，但是通信组件的话你需要用对应第三方库的。

[lz-freedom]

---

如果一个 api 模块下的接口文件太多，建议将复杂的 api 模块进一步划分为子模块。这样可以对复杂的 api 模块进行解耦，也能通过多目录的方式来维护 api 接口定义和 controller 接口实现文件。目录结构会更清晰，更利于多人协作和版本管理

大佬，关于这个能给个示例吗？如何划分为子模块，目前结构已经定死了/api/模块/版本/定义文件.go，改动这个结构会导致生成不了controller

我理解是改成这样：/api/模块/版本/子模块/定义文件.go
例：

• /api/admin/v1/sys/admin_user.go
• /api/admin/v1/order/invoice.go

---

但是按照目前的gen 的设计，只能改成：

• /api/admin_sys/v1/admin_user.go
• /api/admin_order/v1/invoice.go