[zeromicro/go-zero]增加okHandler以支持处理统一响应

7

建议通过模板搞定这个哈

package handler

import (
    "net/http"

    {{.ImportPackages}}
)

func {{.HandlerName}}(ctx *svc.ServiceContext) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        {{if .HasRequest}}var req types.{{.RequestType}}
        if err := httpx.Parse(r, &req); err != nil {
            httpx.Error(w, err)
            return
        }{{end}}

        l := logic.New{{.LogicType}}(r.Context(), ctx)
        {{if .HasResp}}resp, {{end}}err := l.{{.Call}}({{if .HasRequest}}req{{end}})
        if err != nil {
            httpx.Error(w, err)
        } else {
            {{if .HasResp}}httpx.OkJson(w, resp){{else}}httpx.Ok(w){{end}}
        }
    }
}

kevwan

4

这个通用返回都需要，为啥不在框架支持一下呢？都自己来定制模板，会增加很多工作量

greyireland

4

其实就在在OkJson上面包了一层，把resp再做一下处理嘛，如果需要何不自己包一层，比如MyOkJson，然后把resp做一下处理再调用httpx.OkJson呢？这样就把你自己的业务逻辑封装好了呢

我期望go-zero能够保持简单并节制的发展，因为每个人都会有自己看起来很理所当然的需求，如果轻易加进来的话，会导致框架的熵增，最后大家也不想用，但我觉得我肯定也会有判断失误的情况，有时还请见谅

kevwan

5

这样的话每个handler都要这么写呀，几十个handler都要这样做，都是重复的代码

karnin

5

不需要呀，统一调用MyOkJson就好了呀，其它都不变，没有重复代码

kevwan

0

我现在都就是每个生成的handler都需要替换一下这个OkJson，比较麻烦，这个响应规范目前是行业的标准了，好未来的响应不是也添加了code和msg嘛，既然是行业标准为啥不添加呢？

greyireland

0

问题是，它并不是一个标准呀，你用法不对吧，你自己包一个方法MyOkJson，然后模板里用MyOkJson就好了？

kevwan

2

行吧，问题不大

greyireland

2

感谢兄弟理解

kevwan

1

用模板挺麻烦的,项目交接的时候还要告诉用哪个模板

ltinyho

9

但是不可能把所有灵活性都写到代码里，比如你用yaml写kubernetes配置的话也需要交接的。

kevwan

1

嗯嗯,现在看到支持 -home 指定模板,把模板放在代码仓库管理了,通过配置的 make 命令去生成,可以接受了!

ltinyho

[zeromicro/go-zero]增加okHandler以支持处理统一响应

回答