深入了解数据校验(Bean Validation):从深处去掌握@Valid的作用(级联校验)以及常用约束注解的解释说明【享学Java】(上)

简介: 深入了解数据校验(Bean Validation):从深处去掌握@Valid的作用(级联校验)以及常用约束注解的解释说明【享学Java】(上)

前言


关于Bean Validation的基本原理篇完结之后,接下来就是小伙伴最为关心的干货:使用篇。

如果说要使用Bean Validation数据校验,我十分相信小伙伴们都能够使用,但估计大都是有个前提的:Spring MVC环境。我极其简单的调查了一下,近乎99%的人都是只把数据校验使用在Spring MVC的Controller层面的,而且几乎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只返回直接为一个类配置的元数据


  1. 它不处理从超类、接口合并的元数据(简单的说你@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;
  ... // 它自己并不处理什么逻辑,参数都是通过构造器传进来的
}


它的继承树:


image.png


三个实现类对应着上面所述的三种元数据类型。本文很显然只需要关注和注解相关的: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一个,调用栈如下图:

image.png


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

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

image.png

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如下:(两个)


image.png


image.png


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


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

相关文章
|
22天前
|
XML Java 编译器
Java注解的底层源码剖析与技术认识
Java注解(Annotation)是Java 5引入的一种新特性,它提供了一种在代码中添加元数据(Metadata)的方式。注解本身并不是代码的一部分,它们不会直接影响代码的执行,但可以在编译、类加载和运行时被读取和处理。注解为开发者提供了一种以非侵入性的方式为代码提供额外信息的手段,这些信息可以用于生成文档、编译时检查、运行时处理等。
59 7
|
2月前
|
XML Java 编译器
Java学习十六—掌握注解:让编程更简单
Java 注解(Annotation)是一种特殊的语法结构,可以在代码中嵌入元数据。它们不直接影响代码的运行,但可以通过工具和框架提供额外的信息,帮助在编译、部署或运行时进行处理。
101 43
Java学习十六—掌握注解:让编程更简单
|
27天前
|
Java 编译器 数据库
Java 中的注解(Annotations):代码中的 “元数据” 魔法
Java注解是代码中的“元数据”标签,不直接参与业务逻辑,但在编译或运行时提供重要信息。本文介绍了注解的基础语法、内置注解的应用场景,以及如何自定义注解和结合AOP技术实现方法执行日志记录,展示了注解在提升代码质量、简化开发流程和增强程序功能方面的强大作用。
66 5
|
1月前
|
Java 开发者 Spring
[Java]自定义注解
本文介绍了Java中的四个元注解(@Target、@Retention、@Documented、@Inherited)及其使用方法,并详细讲解了自定义注解的定义和使用细节。文章还提到了Spring框架中的@AliasFor注解,通过示例帮助读者更好地理解和应用这些注解。文中强调了注解的生命周期、继承性和文档化特性,适合初学者和进阶开发者参考。
63 14
|
1月前
|
前端开发 Java
[Java]讲解@CallerSensitive注解
本文介绍了 `@CallerSensitive` 注解及其作用,通过 `Reflection.getCallerClass()` 方法返回调用方的 Class 对象。文章还详细解释了如何通过配置 VM Options 使自定义类被启动类加载器加载,以识别该注解。涉及的 VM Options 包括 `-Xbootclasspath`、`-Xbootclasspath/a` 和 `-Xbootclasspath/p`。最后,推荐了几篇关于 ClassLoader 的详细文章,供读者进一步学习。
37 12
|
2月前
|
Java
Java Set以其“不重复”的特性,为我们提供了一个高效、简洁的处理唯一性约束数据的方式。
【10月更文挑战第16天】在Java编程中,Set接口确保集合中没有重复元素,每个元素都是独一无二的。HashSet基于哈希表实现,提供高效的添加、删除和查找操作;TreeSet则基于红黑树实现,不仅去重还能自动排序。通过这两个实现类,我们可以轻松处理需要唯一性约束的数据,提升代码质量和效率。
43 2
|
2月前
|
算法 Java 数据处理
从HashSet到TreeSet,Java集合框架中的Set接口及其实现类以其独特的“不重复性”要求,彻底改变了处理唯一性约束数据的方式。
【10月更文挑战第14天】从HashSet到TreeSet,Java集合框架中的Set接口及其实现类以其独特的“不重复性”要求,彻底改变了处理唯一性约束数据的方式。本文深入探讨Set的核心理念,并通过示例代码展示了HashSet和TreeSet的特点和应用场景。
23 2
|
1月前
|
Java 编译器
Java进阶之标准注解
Java进阶之标准注解
37 0
|
2月前
|
JSON Java 数据库
java 常用注解大全、注解笔记
关于Java常用注解的大全和笔记,涵盖了实体类、JSON处理、HTTP请求映射等多个方面的注解使用。
49 0
java 常用注解大全、注解笔记
|
3月前
|
Arthas Java 测试技术
Java字节码文件、组成,jclasslib插件、阿里arthas工具,Java注解
Java字节码文件、组成、详解、分析;常用工具,jclasslib插件、阿里arthas工具;如何定位线上问题;Java注解
Java字节码文件、组成,jclasslib插件、阿里arthas工具,Java注解