共计 6792 个字符,预计需要花费 17 分钟才能阅读完成。
写得好的没我写得全,写得全的没我写得好
引言
不晓得大家平时的业务开发过程中 controller 层的参数校验都是怎么写的?是否也存在上面这样的直接判断?
public String add(UserVO userVO) {if(userVO.getAge() == null){return "年龄不能为空";}
if(userVO.getAge() > 120){return "年龄不能超过 120";}
if(userVO.getName().isEmpty()){return "用户名不能为空";}
// 省略一堆参数校验...
return "OK";
}
业务代码还没开始写呢,光参数校验就写了一堆判断。这样写尽管没什么错,然而给人的感觉就是:不优雅,不业余。
其实 Spring
框架曾经给咱们封装了一套校验组件:validation。其特点是简略易用,自由度高。接下来课代表应用 springboot-2.3.1.RELEASE
搭建一个简略的 Web 工程,给大家一步一步解说在开发过程中如何优雅地做参数校验。
1. 环境搭建
从 springboot-2.3
开始,校验包被独立成了一个 starter
组件,所以须要引入如下依赖:
<!-- 校验组件 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
<!--web 组件 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
而 springboot-2.3
之前的版本只须要引入 web 依赖就能够了。
2. 小试牛刀
参数校验非常简单,首先在待校验字段上减少校验规定注解
public class UserVO {@NotNull(message = "age 不能为空")
private Integer age;
}
而后在 controller
办法中增加 @Validated
和用于接管错误信息的 BindingResult
就能够了,于是有了第一版:
public String add1(@Validated UserVO userVO, BindingResult result) {List<FieldError> fieldErrors = result.getFieldErrors();
if(!fieldErrors.isEmpty()){return fieldErrors.get(0).getDefaultMessage();}
return "OK";
}
通过工具 (postman) 去申请接口,如果参数不合乎规定,会将相应的 message
信息返回:
age 不能为空
内置的校验注解有很多,列举如下:
注解 | 校验性能 |
---|---|
@AssertFalse | 必须是 false |
@AssertTrue | 必须是 true |
@DecimalMax | 小于等于给定的值 |
@DecimalMin | 大于等于给定的值 |
@Digits | 可设定最大整数位数和最大小数位数 |
校验是否合乎 Email 格局 | |
@Future | 必须是未来的工夫 |
@FutureOrPresent | 以后或未来工夫 |
@Max | 最大值 |
@Min | 最小值 |
@Negative | 正数(不包含 0) |
@NegativeOrZero | 正数或 0 |
@NotBlank | 不为 null 并且蕴含至多一个非空白字符 |
@NotEmpty | 不为 null 并且不为空 |
@NotNull | 不为 null |
@Null | 为 null |
@Past | 必须是过来的工夫 |
@PastOrPresent | 必须是过来的工夫,蕴含当初 |
@PositiveOrZero | 负数或 0 |
@Size | 校验容器的元素个数 |
3. 标准返回值
待校验参数多了之后咱们心愿一次返回所有校验失败信息,不便接口调用方进行调整,这就须要对立返回格局,常见的就是封装一个后果类。
public class ResultInfo<T>{
private Integer status;
private String message;
private T response;
// 省略其余代码...
}
革新一下controller
办法,第二版:
public ResultInfo add2(@Validated UserVO userVO, BindingResult result) {List<FieldError> fieldErrors = result.getFieldErrors();
List<String> collect = fieldErrors.stream()
.map(o -> o.getDefaultMessage())
.collect(Collectors.toList());
return new ResultInfo<>().success(400,"申请参数谬误",collect);
}
申请该办法时,所有的谬误参数就都返回了:
{
"status": 400,
"message": "申请参数谬误",
"response": ["年龄必须在 [1,120] 之间",
"bg 字段的整数位最多为 3 位,小数位最多为 1 位",
"name 不能为空",
"email 格局谬误"
]
}
4. 全局异样解决
每个 Controller
办法中都如果都写一遍对 BindingResult
信息的解决,应用起来还是很繁琐。能够通过全局异样解决的形式对立解决校验异样。
当咱们写了 @validated
注解,不写 BindingResult
的时候,Spring 就会抛出异样。由此,能够写一个全局异样解决类来对立解决这种校验异样,从而免去反复组织异样信息的代码。
全局异样解决类只须要在类上标注 @RestControllerAdvice
,并在解决相应异样的办法上应用@ExceptionHandler
注解,写明解决哪个异样即可。
@RestControllerAdvice
public class GlobalControllerAdvice {
private static final String BAD_REQUEST_MSG = "客户端申请参数谬误";
// <1> 解决 form data 形式调用接口校验失败抛出的异样
@ExceptionHandler(BindException.class)
public ResultInfo bindExceptionHandler(BindException e) {List<FieldError> fieldErrors = e.getBindingResult().getFieldErrors();
List<String> collect = fieldErrors.stream()
.map(o -> o.getDefaultMessage())
.collect(Collectors.toList());
return new ResultInfo().success(HttpStatus.BAD_REQUEST.value(), BAD_REQUEST_MSG, collect);
}
// <2> 解决 json 申请体调用接口校验失败抛出的异样
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResultInfo methodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) {List<FieldError> fieldErrors = e.getBindingResult().getFieldErrors();
List<String> collect = fieldErrors.stream()
.map(o -> o.getDefaultMessage())
.collect(Collectors.toList());
return new ResultInfo().success(HttpStatus.BAD_REQUEST.value(), BAD_REQUEST_MSG, collect);
}
// <3> 解决单个参数校验失败抛出的异样
@ExceptionHandler(ConstraintViolationException.class)
public ResultInfo constraintViolationExceptionHandler(ConstraintViolationException e) {Set<ConstraintViolation<?>> constraintViolations = e.getConstraintViolations();
List<String> collect = constraintViolations.stream()
.map(o -> o.getMessage())
.collect(Collectors.toList());
return new ResultInfo().success(HttpStatus.BAD_REQUEST.value(), BAD_REQUEST_MSG, collect);
}
}
事实上,在全局异样解决类中,咱们能够写多个异样解决办法,课代表总结了三种参数校验时可能引发的异样:
- 应用 form data 形式调用接口,校验异样抛出 BindException
- 应用 json 申请体调用接口,校验异样抛出 MethodArgumentNotValidException
- 单个参数校验异样抛出 ConstraintViolationException
注:单个参数校验须要在参数上减少校验注解,并在类上标注
@Validated
。
全局异样解决类能够增加各种须要解决的异样,比方增加一个对 Exception.class
的异样解决,当所有 ExceptionHandler
都无奈解决时,由其记录异样信息,并返回敌对提醒。
5. 分组校验
如果同一个参数,须要在不同场景下利用不同的校验规定,就须要用到分组校验了。比方:新注册用户还没起名字,咱们容许 name
字段为空,然而不容许将名字更新为空字符。
分组校验有三个步骤:
- 定义一个分组类(或接口)
- 在校验注解上增加
groups
属性指定分组 Controller
办法的@Validated
注解增加分组类
public interface Update extends Default{}
public class UserVO {@NotBlank(message = "name 不能为空",groups = Update.class)
private String name;
// 省略其余代码...
}
@PostMapping("update")
public ResultInfo update(@Validated({Update.class}) UserVO userVO) {return new ResultInfo().success(userVO);
}
仔细的同学可能曾经留神到,自定义的 Update
分组接口继承了 Default
接口。校验注解 (如: @NotBlank
) 和@validated
默认都属于 Default.class
分组,这一点在 javax.validation.groups.Default
正文中有阐明
/**
* Default Jakarta Bean Validation group.
* <p>
* Unless a list of groups is explicitly defined:
* <ul>
* <li>constraints belong to the {@code Default} group</li>
* <li>validation applies to the {@code Default} group</li>
* </ul>
* Most structural constraints should belong to the default group.
*
* @author Emmanuel Bernard
*/
public interface Default {}
在编写 Update
分组接口时,如果继承了Default
,上面两个写法就是等效的:
@Validated({Update.class})
@Validated({Update.class,Default.class})
申请一下 /update
接口能够看到,不仅校验了 name
字段,也校验了其余默认属于 Default.class
分组的字段
{
"status": 400,
"message": "客户端申请参数谬误",
"response": [
"name 不能为空",
"age 不能为空",
"email 不能为空"
]
}
如果 Update
不继承 Default
,@Validated({Update.class})
就只会校验属于 Update.class
分组的参数字段,批改后再次申请该接口失去如下后果,能够看到,其余字段没有参加校验:
{
"status": 400,
"message": "客户端申请参数谬误",
"response": ["name 不能为空"]
}
6. 递归校验
如果 UserVO 类中减少一个 OrderVO 类的属性,而 OrderVO 中的属性也须要校验,就用到递归校验了,只有在相应属性上减少 @Valid
注解即可实现(对于汇合同样实用)
OrderVO 类如下
public class OrderVO {
@NotNull
private Long id;
@NotBlank(message = "itemName 不能为空")
private String itemName;
// 省略其余代码...
}
在 UserVO 类中减少一个 OrderVO 类型的属性
public class UserVO {@NotBlank(message = "name 不能为空",groups = Update.class)
private String name;
// 须要递归校验的 OrderVO
@Valid
private OrderVO orderVO;
// 省略其余代码...
}
调用申请验证如下:
7. 自定义校验
Spring 的 validation 为咱们提供了这么多个性,简直能够满足日常开发中绝大多数参数校验场景了。然而,一个好的框架肯定是不便扩大的。有了扩大能力,就能应答更多简单的业务场景,毕竟在开发过程中,惟一不变的就是变动自身。
Spring Validation 容许用户自定义校验,实现很简略,分两步:
- 自定义校验注解
- 编写校验者类
代码也很简略,联合正文你一看就能懂
@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})
@Retention(RUNTIME)
@Documented
@Constraint(validatedBy = {HaveNoBlankValidator.class})// 表明由哪个类执行校验逻辑
public @interface HaveNoBlank {
// 校验出错时默认返回的音讯
String message() default "字符串中不能含有空格";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
/**
* 同一个元素上指定多个该注解时应用
*/
@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER, TYPE_USE})
@Retention(RUNTIME)
@Documented
public @interface List {NotBlank[] value();}
}
public class HaveNoBlankValidator implements ConstraintValidator<HaveNoBlank, String> {
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
// null 不做测验
if (value == null) {return true;}
if (value.contains(" ")) {
// 校验失败
return false;
}
// 校验胜利
return true;
}
}
自定义校验注解应用起来和内置注解无异,在须要的字段上增加相应注解即可,同学们能够自行验证
回顾
以上就是如何应用 Spring Validation 优雅地校验参数的全部内容,上面重点总结一下文中提到的校验个性
- 内置多种罕用校验注解
- 反对单个参数校验
- 联合全局异样解决主动组装校验异样
- 分组校验
- 反对递归校验
- 自定义校验
本文代码已上传至
GitHub
???? 关注 Java 课代表,获取最新 Java 干货????