前言
关于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。它的作用和特点如下:
- 基于不同的元数据:如xml、注解。(还有个编程映射) 这三种类型。对应的枚举类为:
public enum ConfigurationSource { ANNOTATION( 0 ), XML( 1 ), API( 2 ); //programmatic API }
- MetaDataProvider只返回直接为一个类配置的元数据
- 它不处理从超类、接口合并的元数据(简单的说你@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()
这个私有方法上。总结一下调用此方法的两个原始入口(一个构造器,一个接口方法):
ValidatorFactory.getValidator()
获取校验器的时候,初始化时会自己new
一个,调用栈如下图:
2.调用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()为空嘛~