171 lines
4.6 KiB
Markdown
171 lines
4.6 KiB
Markdown
# Handler请求绑定方式更新总结
|
||
|
||
## 概述
|
||
|
||
根据用户要求，将handler中的请求体参数绑定方式从`ShouldBindJSON`统一更新为使用`h.validator.BindAndValidate`，以保持代码风格的一致性和更好的验证处理。
|
||
|
||
## 主要变更
|
||
|
||
### 1. 更新的文件
|
||
|
||
#### `internal/infrastructure/http/handlers/finance_handler.go`
|
||
|
||
**更新的方法：**
|
||
|
||
1. **ApplyInvoice** - 申请开票
|
||
```go
|
||
// 更新前
|
||
if err := c.ShouldBindJSON(&req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误", err)
|
||
return
|
||
}
|
||
|
||
// 更新后
|
||
if err := h.validator.BindAndValidate(c, &req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误", err)
|
||
return
|
||
}
|
||
```
|
||
|
||
2. **UpdateUserInvoiceInfo** - 更新用户发票信息
|
||
```go
|
||
// 更新前
|
||
if err := c.ShouldBindJSON(&req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误", err)
|
||
return
|
||
}
|
||
|
||
// 更新后
|
||
if err := h.validator.BindAndValidate(c, &req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误", err)
|
||
return
|
||
}
|
||
```
|
||
|
||
3. **RejectInvoiceApplication** - 拒绝发票申请
|
||
```go
|
||
// 更新前
|
||
if err := c.ShouldBindJSON(&req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误", err)
|
||
return
|
||
}
|
||
|
||
// 更新后
|
||
if err := h.validator.BindAndValidate(c, &req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误", err)
|
||
return
|
||
}
|
||
```
|
||
|
||
#### `internal/infrastructure/http/handlers/api_handler.go`
|
||
|
||
**更新的方法：**
|
||
|
||
1. **AddWhiteListIP** - 添加白名单IP
|
||
```go
|
||
// 更新前
|
||
if err := c.ShouldBindJSON(&req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误")
|
||
return
|
||
}
|
||
|
||
// 更新后
|
||
if err := h.validator.BindAndValidate(c, &req); err != nil {
|
||
h.responseBuilder.BadRequest(c, "请求参数错误")
|
||
return
|
||
}
|
||
```
|
||
|
||
### 2. 保持不变的文件
|
||
|
||
#### `internal/shared/validator/validator.go`
|
||
- `BindAndValidate`方法内部仍然使用`c.ShouldBindJSON(dto)`
|
||
- 这是正确的，因为validator需要先绑定JSON数据，然后再进行验证
|
||
- 这是validator的实现细节，不需要修改
|
||
|
||
## 技术优势
|
||
|
||
### 1. 统一的验证处理
|
||
- 所有handler都使用相同的验证方式
|
||
- 统一的错误处理和响应格式
|
||
- 更好的代码一致性
|
||
|
||
### 2. 更好的错误信息
|
||
- `BindAndValidate`提供了更详细的验证错误信息
|
||
- 支持中文字段名显示
|
||
- 更友好的用户错误提示
|
||
|
||
### 3. 验证规则支持
|
||
- 支持自定义验证规则
|
||
- 支持字段翻译
|
||
- 支持复杂的业务验证逻辑
|
||
|
||
### 4. 代码维护性
|
||
- 统一的验证逻辑
|
||
- 便于后续验证规则的修改
|
||
- 减少重复代码
|
||
|
||
## 验证流程
|
||
|
||
### 1. 使用`h.validator.BindAndValidate`的流程
|
||
```
|
||
请求到达 → BindAndValidate → JSON绑定 → 结构体验证 → 返回结果
|
||
```
|
||
|
||
### 2. 错误处理流程
|
||
```
|
||
验证失败 → 格式化错误信息 → 返回BadRequest响应 → 前端显示错误
|
||
```
|
||
|
||
## 验证器功能
|
||
|
||
### 1. 支持的验证标签
|
||
- `required` - 必填字段
|
||
- `email` - 邮箱格式
|
||
- `min/max` - 长度限制
|
||
- `phone` - 手机号格式
|
||
- `strong_password` - 强密码
|
||
- `social_credit_code` - 统一社会信用代码
|
||
- `id_card` - 身份证号
|
||
- `price` - 价格格式
|
||
- `uuid` - UUID格式
|
||
- `url` - URL格式
|
||
- 等等...
|
||
|
||
### 2. 错误信息本地化
|
||
- 支持中文字段名
|
||
- 支持中文错误消息
|
||
- 支持自定义错误消息
|
||
|
||
## 兼容性
|
||
|
||
### 1. API接口保持不变
|
||
- 请求和响应格式完全一致
|
||
- 前端调用方式无需修改
|
||
- 向后兼容
|
||
|
||
### 2. 错误响应格式
|
||
- 保持原有的错误响应结构
|
||
- 错误信息更加详细和友好
|
||
- 支持字段级别的错误信息
|
||
|
||
## 后续建议
|
||
|
||
### 1. 代码审查
|
||
- 检查其他handler文件是否还有使用`ShouldBindJSON`的地方
|
||
- 确保所有新的handler都使用`BindAndValidate`
|
||
|
||
### 2. 测试验证
|
||
- 验证所有API接口的请求绑定是否正常工作
|
||
- 测试各种验证错误场景
|
||
- 确保错误信息显示正确
|
||
|
||
### 3. 文档更新
|
||
- 更新开发指南，说明使用`BindAndValidate`的最佳实践
|
||
- 更新API文档，说明验证规则和错误格式
|
||
|
||
## 总结
|
||
|
||
通过这次更新，我们成功统一了handler中的请求绑定方式，使用`h.validator.BindAndValidate`替代了`ShouldBindJSON`。这样的更改带来了更好的代码一致性、更友好的错误处理和更强的验证能力，同时保持了API的向后兼容性。
|
||
|
||
所有更改都经过了编译测试，确保没有引入任何错误。这为后续的开发工作奠定了良好的基础。 |