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 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 扩展提供了直接在注解层面指定分组的能力
我们知道 JSR 提供了一个 @Valid 注解供以使用,在本文之前,绝大多数小伙伴都是在 Controller 中并且结合 @RequestBody 一起来使用它,但在本文之后,你定会对它有个全新的认识~
==该注解用于验证 级联的属性 、 方法参数 或 方法返回 类型。==
当验证属性、方法参数或方法返回类型时,将验证对象及其属性上定义的约束,另外: 此行为是递归应用的。
:::为了理解 @Valid ,那就得知道处理它的时机:::
元数据提供者:约束相关元数据(如约束、 默认组序列 等)的 Provider 。它的作用和特点如下:
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
这个元数据均来自于注解的标注,然后它是 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 一个,调用栈如下图:
调用 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 : clazz.getDeclaredFields() 把每个 Field 都包装成 ConstrainedElement 存放起来~~~
1. 注意:此步骤完成了对每个`Field`上标注的注解进行了保存
Method : clazz.getDeclaredMethods() 把每个Method都转换成一个 ConstrainedExecutable 装着~~( ConstrainedExecutable 也是个 ConstrainedElement )。在此期间它完成了如下事( 方法和构造器都复杂点,因为包含入参和返回值 ):
1. 找到方法上所有的注解保存起来
2. 处理入参、返回值(包括自动判断是作用在入参还是返回值上) 完全同处理Method,略
ConstraintDescriptor 对已经找到每个 ConstraintDescriptor 进行处理,最终都转换 Set<MetaConstraint<?>> 这个类型
1.
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 一把吧:==
上面用一个示例校验 Person 这个 JavaBean 了,但是你会发现示例中我们全都是校验的 Field 属性。从理论里我们知道了 Bean Validation 它是有校验 方法、构造器、入参甚至递归校验级联属性的能力的 :
略
这些是不能直接使用的,需要在运行时进行校验。具体使用可参考: 【小家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入群" 字样,会手动邀请入群**