Обзор
Сначала синхронизируйте обзор проекта:
В последней опубликованной статье используются модули go для инициализации проекта, в этой статье мы делимся:
- Планирование структуры каталогов
- Привязка и проверка модели
- пользовательский валидатор
- Разработать структуру возврата API
Без дальнейших церемоний, давайте начнем.
Планирование структуры каталогов
├─ go-gin-api
│ ├─ app
│ ├─ config //配置文件
│ ├─ config.go
│ ├─ controller //控制器层
│ ├─ param_bind
│ ├─ param_verify
│ ├─ ...
│ ├─ model //数据库ORM
│ ├─ proto
│ ├─ ...
│ ├─ repository //数据库操作层
│ ├─ ...
│ ├─ route //路由
│ ├─ middleware
│ ├─ route.go
│ ├─ service //业务层
│ ├─ ...
│ ├─ util //工具包
│ ├─ ...
│ ├─ vendor //依赖包
│ ├─ ...
│ ├─ go.mod
│ ├─ go.sum
│ ├─ main.go //入口文件
Приведенная выше структура каталогов настроена мной, и вы также можете определить ее в соответствии со своими привычками.
контроллер Уровень контроллера в основном проверяет отправленные данные, а затем передает проверенные данные службе для обработки.
Во фреймворке gin существует два типа проверки параметров:
1. Привязка и проверка модели.
2. Пользовательский валидатор.
каталог которогоparam_bind
, в котором хранятся данные, привязанные к параметру, директорияparam_verify
Сохраняются пользовательские валидаторы.
Далее, давайте сделаем простую реализацию.
Привязка и проверка модели
Например, если есть интерфейс для создания продукта, название продукта не может быть пустым.
Настройте маршрут (route.go):
ProductRouter := engine.Group("")
{
// 新增产品
ProductRouter.POST("/product", product.Add)
// 更新产品
ProductRouter.PUT("/product/:id", product.Edit)
// 删除产品
ProductRouter.DELETE("/product/:id", product.Delete)
// 获取产品详情
ProductRouter.GET("/product/:id", product.Detail)
}
Привязка параметров (param_bind/product.go):
type ProductAdd struct {
Name string `form:"name" json:"name" binding:"required"`
}
Вызов контроллера (controller/product.go):
if err := c.ShouldBind(¶m_bind.ProductAdd{}); err != nil {
utilGin.Response(-1, err.Error(), nil)
return
}
Когда мы используем Postman для имитации почтового запроса, если параметр name не передан или передан пустым, он появится:
Key: 'ProductAdd.Name' Error:Field validation for 'Name' failed on the 'required' tag
Это использует настройки параметровbinding:"required"
.
Так какие параметры еще можно использовать в биндинге, есть ли документация?
имеют. Джин использует go-playground/validator.v8 для проверки, связанные документы:
перейти на doc.org/GOP кг.in/go…
Далее давайте реализуем собственный валидатор.
пользовательский валидатор
Например, если есть интерфейс для создания продукта, имя продукта не может быть пустым, а имя параметра не может быть равным admin.
Подобно этому бизнес-требованию, невозможно связать готовые методы, и для этого нам нужно написать собственные методы проверки.
Пользовательский метод проверки (param_verify/product.go)
func NameValid (
v *validator.Validate, topStruct reflect.Value, currentStructOrField reflect.Value,
field reflect.Value, fieldType reflect.Type, fieldKind reflect.Kind, param string,
) bool {
if s, ok := field.Interface().(string); ok {
if s == "admin" {
return false
}
}
return true
}
Привязка параметров (param_bind/product.go):
type ProductAdd struct {
Name string `form:"name" json:"name" binding:"required,NameValid"`
}
Также привяжите валидатор:
// 绑定验证器
if v, ok := binding.Validator.Engine().(*validator.Validate); ok {
v.RegisterValidation("NameValid", param_verify.NameValid)
}
Когда мы используем Postman для имитации почтового запроса, если параметр name не передан или передан пустым, он появится:
Key: 'ProductAdd.Name' Error:Field validation for 'Name' failed on the 'required' tag
Когда имя=админ:
Key: 'ProductAdd.Name' Error:Field validation for 'Name' failed on the 'NameValid' tag
Хорошо, две вышеуказанные проверки действительны!
Приведенный выше вывод находится в консоли, можете ли вы вернуть данные структуры Json?
может. Далее мы формулируем структуру возврата API.
Разработать структуру возврата API
{
"code": 1,
"msg": "",
"data": null
}
Структура, возвращаемая интерфейсом API, в основном представляет собой эти три поля.
Например, code=1 означает успех, code=-1 означает неудачу.
msg указывает оперативную информацию.
data представляет данные, которые должны быть возвращены.
Итак, как мы реализуем это во фреймворке gin, на самом деле это очень просто на основеc.JSON()
Метод можно инкапсулировать, просто посмотрите на код напрямую.
package util
import "github.com/gin-gonic/gin"
type Gin struct {
Ctx *gin.Context
}
type response struct {
Code int `json:"code"`
Message string `json:"msg"`
Data interface{} `json:"data"`
}
func (g *Gin)Response(code int, msg string, data interface{}) {
g.Ctx.JSON(200, response{
Code : code,
Message : msg,
Data : data,
})
return
}
Вызов контроллера (controller/product.go):
utilGin := util.Gin{Ctx:c}
if err := c.ShouldBind(¶m_bind.ProductAdd{}); err != nil {
utilGin.Response(-1, err.Error(), nil)
return
}
Когда мы используем Postman для имитации почтового запроса, если параметр name не передан или передан пустым, он появится:
{
"code": -1,
"msg": "Key: 'ProductAdd.Name' Error:Field validation for 'Name' failed on the 'required' tag",
"data": null
}
Когда имя=админ:
{
"code": -1,
"msg": "Key: 'ProductAdd.Name' Error:Field validation for 'Name' failed on the 'NameValid' tag",
"data": null
}
Хорошо, две вышеуказанные проверки действительны!