从深处去掌握数据校验Valid的作用级联校验

39次阅读

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

每篇一句

NBA 里有两大笑话:一是科比没天赋,二是詹姆斯没技术

相关阅读

【小家 Java】深入了解数据校验:Java Bean Validation 2.0(JSR303、JSR349、JSR380)Hibernate-Validation 6.x 使用案例
【小家 Spring】让 Controller 支持对平铺参数执行数据校验(默认 Spring MVC 使用 @Valid 只能对 JavaBean 进行校验)
【小家 Spring】Spring 方法级别数据校验:@Validated + MethodValidationPostProcessor 优雅的完成数据校验动作


<center> 对 Spring 感兴趣可扫码加入 wx 群:Java 高工、架构师 3 群(文末有二维码)</center>


前言

关于 Bean Validation 的基本原理篇完结之后,接下来就是小伙伴最为关心的干货:使用篇
如果说要使用 Bean Validation 数据校验,我十分相信小伙伴们都能够使用,但估计大都是有个前提的:Spring MVC环境。我极其简单的调查了一下,近乎 99% 的人都是只把数据校验使用在 Spring MVCController层面的,而且几乎 90% 的人都是让它必须和 @RequestBody 一起来使用去校验 JavaBean 入参~

如果这么去理解 Bean Validation 的使用,那就有点太过于片面了,毕竟被 Spring 包裹起来,你其实很难去知道它真正做的事。
熟悉我文章风格的人知道,每篇文章我都会带你领略一些不一样的风景,本章亦不例外 ,会让你知道数据校验在Spring 框架之外的一些事~

分组校验

在我的前置原理篇文章,分组校验其实是没太大必要说的,因为使用起来确实非常的简单。此处还是给个分组校验的使用案例吧:

@Getter
@Setter
@ToString
public class Person {
    // 错误消息 message 是可以自定义的
    @NotNull(message = "{message} -> 名字不能为 null", groups = Simple.class)
    public String name;
    @Max(value = 10, groups = Simple.class)
    @Positive(groups = Default.class) // 内置的分组:default
    public Integer age;

    @NotNull(groups = Complex.class)
    @NotEmpty(groups = Complex.class)
    private List<@Email String> emails;
    @Future(groups = Complex.class)
    private Date start;

    // 定义两个组 Simple 组和 Complex 组
    interface Simple { }
    interface Complex {}}

执行分组校验:

    public static void main(String[] args) {Person person = new Person();
        //person.setName("fsx");
        person.setAge(18);
        // email 校验:虽然是 List 都可以校验哦
        person.setEmails(Arrays.asList("fsx@gmail.com", "baidu@baidu.com", "aaa.com"));
        //person.setStart(new Date()); //start 需要是一个将来的时间: Sun Jul 21 10:45:03 CST 2019
        //person.setStart(new Date(System.currentTimeMillis() + 10000)); // 校验通过

        HibernateValidatorConfiguration configure = Validation.byProvider(HibernateValidator.class).configure();
        ValidatorFactory validatorFactory = configure.failFast(false).buildValidatorFactory();
        // 根据 validatorFactory 拿到一个 Validator
        Validator validator = validatorFactory.getValidator();


        // 分组校验(可以区分对待 Default 组、Simple 组、Complex 组)Set<ConstraintViolation<Person>> result = validator.validate(person, Person.Simple.class);
        //Set<ConstraintViolation<Person>> result = validator.validate(person, Person.Complex.class);

        // 对结果进行遍历输出
        result.stream().map(v -> v.getPropertyPath() + "" + v.getMessage() +": " + v.getInvalidValue())
                .forEach(System.out::println);

    }

运行打印:

age 最大不能超过 10: 18
name {message} -> 名字不能为 null -> 名字不能为 null: null

可以直观的看到效果,此处的校验只执行 Person.Simple.class 这个 Group 组上的约束~

分组约束在 Spring MVC 中的使用场景还是相对比较多的,但是需要注意的是:javax.validation.Valid没有提供指定分组的,但是 org.springframework.validation.annotation.Validated 扩展提供了直接在注解层面指定分组的能力

@Valid 注解

我们知道 JSR 提供了一个 @Valid 注解供以使用,在本文之前,绝大多数小伙伴都是在 Controller 中并且结合 @RequestBody 一起来使用它,但在本文之后,你定会对它有个全新的认识~

== 该注解用于验证 级联的属性 方法参数 方法返回 类型。==
当验证属性、方法参数或方法返回类型时,将验证对象及其属性上定义的约束,另外:此行为是递归应用的。

:::为了理解@Valid,那就得知道处理它的时机:::

MetaDataProvider

元数据提供者:约束相关元数据(如约束、默认组序列 等)的Provider。它的作用和特点如下:

  1. 基于不同的元数据:如 xml、注解。(还有个编程映射) 这三种类型。对应的枚举类为:
public enum ConfigurationSource {ANNOTATION( 0),
    XML(1),
    API(2); //programmatic API
}
  1. MetaDataProvider只返回 直接为一个类配置的 元数据
  2. 它不处理从超类、接口合并的元数据(简单的说你 @Valid 放在接口处是无效的
public interface MetaDataProvider {

    // 将 ** 注解处理选项 ** 归还给此 Provider 配置。它的唯一实现类为:AnnotationProcessingOptionsImpl
    // 它可以配置比如:areMemberConstraintsIgnoredFor  areReturnValueConstraintsIgnoredFor
    // 也就说可以配置:让免于被校验~~~~~~(开绿灯用的)
    AnnotationProcessingOptions getAnnotationProcessingOptions();
    // 返回作用在此 Bean 上面的 `BeanConfiguration`   若没有就返回 null 了
    // BeanConfiguration 持有 ConfigurationSource 的引用~
    <T> BeanConfiguration<? super T> getBeanConfiguration(Class<T> beanClass);
    
}

// 表示源于一个 ConfigurationSource 的一个 Java 类型的完整约束相关配置。包含字段、方法、类级别上的元数据
// 当然还包含有默认组序列上的元数据(使用较少)public class BeanConfiguration<T> {
    // 三种来源的枚举
    private final ConfigurationSource source;
    private final Class<T> beanClass;
    // ConstrainedElement 表示待校验的元素,可以知道它会如下四个子类:// ConstrainedField/ConstrainedType/ConstrainedParameter/ConstrainedExecutable
    
    // 注意:ConstrainedExecutable 持有的是 java.lang.reflect.Executable 对象
    // 它的两个子类是 java.lang.reflect.Method 和 Constructor
    private final Set<ConstrainedElement> constrainedElements;

    private final List<Class<?>> defaultGroupSequence;
    private final DefaultGroupSequenceProvider<? super T> defaultGroupSequenceProvider;
    ... // 它自己并不处理什么逻辑,参数都是通过构造器传进来的
}

它的继承树:

三个实现类对应着上面所述的三种元数据类型。本文很显然只需要关注和注解相关的:AnnotationMetaDataProvider

AnnotationMetaDataProvider

这个元数据均来自于注解的标注 ,然后它是Hibernate Validation 的默认 configuration source。它这里会处理标注有@Valid 的元素~

public class AnnotationMetaDataProvider implements MetaDataProvider {

    private final ConstraintHelper constraintHelper;
    private final TypeResolutionHelper typeResolutionHelper;
    private final AnnotationProcessingOptions annotationProcessingOptions;
    private final ValueExtractorManager valueExtractorManager;

    // 这是一个非常重要的属性,它会记录着当前 Bean  所有的待校验的 Bean 信息~~~
    private final BeanConfiguration<Object> objectBeanConfiguration;

    // 唯一构造函数
    public AnnotationMetaDataProvider(ConstraintHelper constraintHelper,
            TypeResolutionHelper typeResolutionHelper,
            ValueExtractorManager valueExtractorManager,
            AnnotationProcessingOptions annotationProcessingOptions) {
        this.constraintHelper = constraintHelper;
        this.typeResolutionHelper = typeResolutionHelper;
        this.valueExtractorManager = valueExtractorManager;
        this.annotationProcessingOptions = annotationProcessingOptions;

        // 默认情况下,它去把 Object 相关的所有的方法都 retrieve: 检索出来放着  我比较费解这件事~~~  
        // 后面才发现:一切为了效率
        this.objectBeanConfiguration = retrieveBeanConfiguration(Object.class);
    }

    // 实现接口方法
    @Override
    public AnnotationProcessingOptions getAnnotationProcessingOptions() {return new AnnotationProcessingOptionsImpl();
    }


    // 如果你的 Bean 是 Object  就直接返回了~~~(大多数情况下  都是 Object)@Override
    @SuppressWarnings("unchecked")
    public <T> BeanConfiguration<T> getBeanConfiguration(Class<T> beanClass) {if ( Object.class.equals( beanClass) ) {return (BeanConfiguration<T>) objectBeanConfiguration;
        }
        return retrieveBeanConfiguration(beanClass);
    }
}

如上可知,核心解析逻辑在 retrieveBeanConfiguration() 这个私有方法上。总结一下调用此方法的两个原始入口(一个构造器,一个接口方法):

  1. ValidatorFactory.getValidator()获取校验器的时候,初始化时会自己 new 一个,调用栈如下图:

  1. 调用 Validator.validate() 方法的时候,beanMetaDataManager.getBeanMetaData(rootBeanClass)它会遍历初始化时所有的 metaDataProviders(默认情况下两个,没有 xml 方式的),拿出所有的BeanConfiguration 交给BeanMetaDataBuilder,最终构建出一个属于此 Bean 的BeanMetaData。对此有一点注意事项描述如下:

        1. 处理 `MetaDataProvider` 时会调用 `ClassHierarchyHelper.getHierarchy(beanClass) ` 方法,不仅仅处理本类。拿到本类自己和所有父类后,统一交给 `provider.getBeanConfiguration(clazz)` 处理(** 也就是说任何一个类都会把 Object 类处理一遍 **)

retrieveBeanConfiguration()详情

这个方法说白了,就是从 Bean 里面去检索属性、方法、构造器等需要校验的ConstrainedElement 项

    private <T> BeanConfiguration<T> retrieveBeanConfiguration(Class<T> beanClass) {// 它检索的范围是:clazz.getDeclaredFields()  什么意思:就是搜集到本类所有的字段  包括 private 等等  但是不包括父类的所有字段
        Set<ConstrainedElement> constrainedElements = getFieldMetaData(beanClass);
        constrainedElements.addAll(getMethodMetaData( beanClass) );
        constrainedElements.addAll(getConstructorMetaData( beanClass) );

        //TODO GM: currently class level constraints are represented by a PropertyMetaData. This
        //works but seems somewhat unnatural
        // 这个 TODO 很有意思:当前,类级约束由 PropertyMetadata 表示。这是可行的,但似乎有点不自然
        // ReturnValueMetaData、ExecutableMetaData、ParameterMetaData、PropertyMetaData

        // 总之吧:此处就是把类级别的校验器放进来了(这个 set 大部分时候都是空的)Set<MetaConstraint<?>> classLevelConstraints = getClassLevelConstraints(beanClass);
        if (!classLevelConstraints.isEmpty()) {ConstrainedType classLevelMetaData = new ConstrainedType(ConfigurationSource.ANNOTATION, beanClass, classLevelConstraints);
            constrainedElements.add(classLevelMetaData);
        }
        
        // 组装成一个 BeanConfiguration 返回
        return new BeanConfiguration<>(ConfigurationSource.ANNOTATION, beanClass,
                constrainedElements, 
                getDefaultGroupSequence(beanClass),  // 此类上标注的所有 @GroupSequence 注解
                getDefaultGroupSequenceProvider(beanClass) // 此类上标注的所有 @GroupSequenceProvider 注解
        );
    }

这一步骤把该 Bean 上的 字段、方法 等等需要校验的项都提取出来。就拿上例中的 Demo 校验 Person 类来说,最终得出的 BeanConfiguration 如下:(两个)


这是直观的结论,可以看到仅仅是一个简单的类其实 所包含的项 是挺多的。

此处说一句:项是有这么多,但是并不是每一个都需要走验证逻辑的。因为毕竟大多数项上面并没有约束(注解),大多数 ConstrainedElement.getConstraints() 为空嘛~

总得来说,我个人建议不能光只记忆结论,因为那很容易忘记,所以还是得稍微深入一点,让记忆更深刻吧。那就从下面四个方面深入:

检索 Field:getFieldMetaData(beanClass)
  1. 拿到 本类 所有字段Fieldclazz.getDeclaredFields()
  2. 把每个 Field 都包装成 ConstrainedElement 存放起来~~~

        1.  注意:此步骤完成了对每个 `Field` 上标注的注解进行了保存
    
检索 Method:getMethodMetaData(beanClass)
  1. 拿到本类所有的方法Methodclazz.getDeclaredMethods()
  2. 排除掉静态方法和合成 (isSynthetic) 方法
  3. 把每个 Method 都转换成一个 ConstrainedExecutable 装着~~(ConstrainedExecutable也是个 ConstrainedElement)。在此期间它完成了如下事( 方法和构造器都复杂点,因为包含入参和返回值):

        1. 找到方法上所有的注解保存起来
        2. 处理入参、返回值(包括自动判断是作用在入参还是返回值上)
检索 Constructor:getConstructorMetaData(beanClass)

完全同处理 Method,略

检索 Type:getClassLevelConstraints(beanClass)
  1. 找打标注在此类上的所有的注解,转换成ConstraintDescriptor
  2. 对已经找到每个 ConstraintDescriptor 进行处理,最终都转换 Set<MetaConstraint<?>> 这个类型

        1. 
  3. Set<MetaConstraint<?>> 用一个 ConstrainedType 包装起来(ConstrainedType是个ConstrainedElement

== 关于级联校验此处补充说明一点,处理 Type,都会处理级联校验情况,并且还是递归处理:==
也就是这个方法(课件 @Valid 在此处生效):

    // type 解释:分如下 N 中情况
    // Field 为:.getGenericType() // 字段的类型
    // Method 为:.getGenericReturnType() // 返回值类型
    // Constructor:.getDeclaringClass() // 构造器所在类

    // annotatedElement:可不一定说一定要有注解才能进来(每个字段、方法、构造器等都能传进来)private CascadingMetaDataBuilder getCascadingMetaData(Type type, AnnotatedElement annotatedElement, Map<TypeVariable<?>, CascadingMetaDataBuilder> containerElementTypesCascadingMetaData) {return CascadingMetaDataBuilder.annotatedObject( type, annotatedElement.isAnnotationPresent( Valid.class), containerElementTypesCascadingMetaData, getGroupConversions(annotatedElement) );
    }

这里对我们理解级联校验最重要的一句是:annotatedElement.isAnnotationPresent(Valid.class)。也就是说:若元素被此注解标注了,那就证明需要对它进行 级联校验 ,这就是 JSR 定位@Valid 的作用~

Spring 提升了它???请关注后文 Spring 对它的应用吧~

ConstraintValidator.isValid()调用处

我们知道,每个约束注解都是交给 约束校验器 ConstraintValidator.isValid()这个方法来处理的,它被 调用 (生效) 的地方在此(唯一处):

public abstract class ConstraintTree<A extends Annotation> {
    ...
    protected final <T, V> Set<ConstraintViolation<T>> validateSingleConstraint(ValidationContext<T> executionContext,
            ValueContext<?, ?> valueContext,
            ConstraintValidatorContextImpl constraintValidatorContext,
            ConstraintValidator<A, V> validator) {
        ...
        V validatedValue = (V) valueContext.getCurrentValidatedValue();
        isValid = validator.isValid(validatedValue, constraintValidatorContext);
        ...
        // 显然校验不通过就返回错误消息  否则返回空集合
        if (!isValid) {return executionContext.createConstraintViolations(valueContext, constraintValidatorContext);
        }
        return Collections.emptySet();}
    ...
}

这个方法的调用,会在执行每个 Group 的时候

success = metaConstraint.validateConstraint(validationContext, valueContext);

MetaConstraint在上面检索的时候就已经准备好了,最后通过 ConstrainedElement.getConstraints 就拿到了每个元素的校验器们,继续调用

// ConstraintTree<A>
boolean validationResult = constraintTree.validateConstraints(executionContext, valueContext);

so,最终就调用到了 isValid 这个 真正做事 的方法上了。

== 说了这么多,你可能还云里雾里,那么就 show 一把吧:==

Demo Show

上面用一个示例校验 Person 这个 JavaBean 了,但是你会发现示例中我们全都是校验的 Field 属性。从理论里我们知道了 Bean Validation 它是有校验 方法、构造器、入参甚至递归校验级联属性的能力的

校验属性 Field

校验 Method 入参、返回值

校验 Constructor 入参、返回值

既校验入参,同时也校验返回值

这些是不能直接使用的,需要在运行时进行校验。具体使用可参考:【小家 Spring】让 Controller 支持对平铺参数执行数据校验(默认 Spring MVC 使用 @Valid 只能对 JavaBean 进行校验)

级联校验

什么叫级联校验,其实就是带校验的成员里存在级联对象时,也要对它完成校验。这个在实际应用场景中是比较常见的,比如入参 Person 对象中,还持有 Child 对象,我们不仅仅要完成 Person 的校验,也依旧还要对 Child 内的属性 校验:

@Getter
@Setter
@ToString
public class Person {

    @NotNull
    private String name;
    @NotNull
    @Positive
    private Integer age;
    @Valid
    @NotNull
    private InnerChild child;

    @Getter
    @Setter
    @ToString
    public static class InnerChild {
        @NotNull
        private String name;
        @NotNull
        @Positive
        private Integer age;
    }

}

校验逻辑如下:

    public static void main(String[] args) {Person person = new Person();
        person.setName("fsx");
        Person.InnerChild child = new Person.InnerChild();
        child.setName("fsx-son");
        child.setAge(-1);
        person.setChild(child); // 放进去

        Validator validator = Validation.byProvider(HibernateValidator.class).configure().failFast(false)
                .buildValidatorFactory().getValidator();
        Set<ConstraintViolation<Person>> result = validator.validate(person);

        // 输出错误消息
        result.stream().map(v -> v.getPropertyPath() + "" + v.getMessage() +": " + v.getInvalidValue())
                .forEach(System.out::println);
    }

运行:

child.age 必须是正数: -1
age 不能为 null: null

child.age 这个级联属性校验成功~

总结

本文值得说是深入了解数据校验(Bean Validation)了,对于数据校验的基本使用一直都不是难事,特别是在 Spring 环境下使用就更简单了~

知识交流

若文章格式混乱,可点击:原文链接 - 原文链接 - 原文链接 - 原文链接 - 原文链接

==The last:如果觉得本文对你有帮助,不妨点个赞呗。当然分享到你的朋友圈让更多小伙伴看到也是被 作者本人许可的~==

** 若对技术内容感兴趣可以加入 wx 群交流:Java 高工、架构师 3 群
若群二维码失效,请加 wx 号:fsx641385712(或者扫描下方 wx 二维码)。并且备注:"java 入群" 字样,会手动邀请入群 **

正文完
 0