写得好的没我写得全,写得全的没我写得好

引言

不晓得大家平时的业务开发过程中 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校验是否合乎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注解,写明解决哪个异样即可。

@RestControllerAdvicepublic 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);    }    }

事实上,在全局异样解决类中,咱们能够写多个异样解决办法,课代表总结了三种参数校验时可能引发的异样:

  1. 应用form data形式调用接口,校验异样抛出 BindException
  2. 应用 json 申请体调用接口,校验异样抛出 MethodArgumentNotValidException
  3. 单个参数校验异样抛出ConstraintViolationException
注:单个参数校验须要在参数上减少校验注解,并在类上标注@Validated

全局异样解决类能够增加各种须要解决的异样,比方增加一个对Exception.class的异样解决,当所有ExceptionHandler都无奈解决时,由其记录异样信息,并返回敌对提醒。

5.分组校验

如果同一个参数,须要在不同场景下利用不同的校验规定,就须要用到分组校验了。比方:新注册用户还没起名字,咱们容许name字段为空,然而不容许将名字更新为空字符。

分组校验有三个步骤:

  1. 定义一个分组类(或接口)
  2. 在校验注解上增加groups属性指定分组
  3. 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容许用户自定义校验,实现很简略,分两步:

  1. 自定义校验注解
  2. 编写校验者类

代码也很简略,联合正文你一看就能懂

@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 优雅地校验参数的全部内容,上面重点总结一下文中提到的校验个性

  1. 内置多种罕用校验注解
  2. 反对单个参数校验
  3. 联合全局异样解决主动组装校验异样
  4. 分组校验
  5. 反对递归校验
  6. 自定义校验

本文代码已上传至
GitHub


????关注 Java课代表,获取最新 Java 干货????