关于go:Golang-PHP-数据绑定漫谈一

41次阅读

共计 2642 个字符,预计需要花费 7 分钟才能阅读完成。

前言:

小编好几个月都没更新啦。注意力都在体验幸福苦涩的的生存在。因为注意力被扩散,在此期间,耳机掉了两副,小米手环掉了两个,四周产生的事件间接性疏忽掉了,恍然间回过神来已过来几个
月。蓦然回首工夫过滴好快呀。得给宝子们来点干货

强类型语言

数据绑定

在强类型语言中,绑定参数分好几种类型。拿最应用宽泛的 Gin web 框架介绍

1、Bind 和 ShouldBind 和 NustBind

Gin 的 Context 为申请数据绑定提供了两大类办法:在命名上以 Bind 为前缀和以 ShouldBind、MustBind 辨别。这两大类办法在行为上有些差别。
类型 形容
must 条件必须要满足
should 条件应该满足

Bind 办法会主动将 http status 设置为 400。而且不会返回更多的信息。因为存在,错误处理简单,限度较多(仅仅反对常见类型),验证规定限度简略,可能存在平安危险等等在日常开发中简直不倡议应用 bind 来绑定数据

ShouldBind、ShouldBindJSON 这些办法的区别是前者会主动依据 Header 头确定应用什么绑定器,如果团队内开发标准里约定了申请 Content-Type 都是 JSON 的话,间接选用后者更为正当。
在理论开发中,ShouldBind 主动依据 Header 头确定应用什么绑定器应用最多。因为团队的约定对新退出的团队的人来说没看到约定的状况下,容易呈现代码不兼容的问题。

var request struct {
  Email string `form:"email" binding:"required"`
  Name  string `form:"name" binding:"required"`
}
// ShouldBind 惯例绑定也能够兼容 post get json 参数
if err := ctx.ShouldBind(&request); err != nil {core.Response(ctx, gin.H{}, err)
  return
}
// Content-Type 都是 JSON 的话,对于强类型语言来说,应用上面这段更正当, 个别状况还是用下面这种。if err := ctx.ShouldBindJson(&request); err != nil {core.Response(ctx, gin.H{}, err)
  return
}

2、单次绑定和屡次绑定 request body 数据

有了下面的绑定根底状况下,小编遇到了这样的一个问题。权限验证 中间件,在接管参数的时候应用的上面代码的接管参数的形式。接口的申请参数是 Content-Type 都是 JSON 的类型的。

message := ctx.PostForm("message")
ids := ctx.QueryMap("ids")
message := ctx.GetQuery("message")

此时此刻,为了让接口绑定参数和中间件绑定参数,就会有二次绑定的数据的问题。小编楞是找了半天,原来强类型语言,简直对类型都有做辨别。不论是 json get post request 类型每种类型都做了辨别,连二次绑定都做了辨别,不得不说,为了性能就义编写代码的体验。所以要害来了

无论是 Bind 还是 ShouldBind 类的绑定办法,都只能读取一次申请体进行绑定

能够应用ShouldBindBodyWith 来实现二次及屡次绑定。那问题又来了,应用了ShouldBindBodyWith 绑定从一个参数被绑定开始,前面的绑定都得应用ShouldBindBodyWith 来绑定,有这样的限度能力实现屡次绑定

if err := ctx.ShouldBindBodyWith(&request,binding.JSON); err != nil {core.Response(ctx, gin.H{}, err)
  return
}

到了这里基本上对参数绑定有了肯定的理解。不同类型须要互相转换,不同的的场景须要不同的办法来实现。绝对于弱类型语言 PHP 来说,不管三七二一,一键全副接管,不论什么类型,一次绑定还是屡次绑定也好,照单全收,这样的解决也间接导致弱类型语言在底层解决上须要兼容各种类型,性能也绝对于强类型语言编译须要更多的内容空间和耗费更多的 CPU 资源。

3、通用类型绑定

在强类型语言中,接管参数的时候,罕用构造体来绑定数据类型。每种构造体定义一种类型。而且首字母要大写。

type request struct {
  Email string `form:"email" binding:"required"`
  Name  string `form:"name" binding:"required"`
  Age   int     `form:"age" binding:"required"`
}

那么问题来了,要接管数据格式为json 数据格式怎么办。貌似繁多的数据 string int 等数据格式都不能满足了,须要嵌套构造体如下:

type Grouping struct {
    ID          int         `json:"id"`
    Remark      string      `json:"remark" default:""`
}
type Group struct {Test1   []*Grouping `json:"test1"`
    Test2   Grouping    `json:"test2"`
    Test3   string      `json:"test3"`
    Test4   int         `json:"test4"`
}

那么问题又来了,这种类型是 json 格局固定的状况下,那么需要有变动,就得更新代码新增构造体字段。减少一个构造体字段,就得从新编译一次。那没有接管通用类型的字段值。

接下来 interface 类型就派上用场了。interface 类型为通用类型,MySQL 数据库没有这种类型。还须要将interface 类型转成 json,string,int 这样的类型能力保留。所以在接管通用数据参数格局的时候,得借助 MySQL 第三方扩大库在标识,接管通用类型是 text string 还是 json 类型

type UserGroupTask struct {Test1  interface{} `json:"test1" form:"test1" gorm:"type:'json'"`
}

通过标识 gorm 标识,interface 类型为json。这样在shouldBindJSON 的时候,能力辨认出是 JSON 格局。

总结

下面介绍了强类型语言,须要对字段类型做转化、数据绑定类型指定等,在弱类型语言中在底层封装好了。
留下一个疑难,下面的代码接管通用格局,怎么在尽可能少写后果体的前提下,把 json 格局的参数取出来做判断后,在入到数据库里去呢。

正文完
 0