从深处去掌握数据校验@Valid的作用（级联校验）
每篇一句
nba里有两大笑话：一是科比没天赋，二是詹姆斯没技术
相关阅读
【小家java】深入了解数据校验：java bean validation 2.0（jsr303、jsr349、jsr380）hibernate-validation 6.x使用案例
【小家spring】让controller支持对平铺参数执行数据校验（默认spring mvc使用@valid只能对javabean进行校验）
【小家spring】spring方法级别数据校验：@validated + methodvalidationpostprocessor优雅的完成数据校验动作
前言
关于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一个，调用栈如下图： - 调用
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 )
- 拿到本类所有字段
field：clazz.getdeclaredfields() - 把每个
field都包装成constrainedelement存放起来~~~
1. 注意：此步骤完成了对每个field上标注的注解进行了保存
检索method：getmethodmetadata( beanclass )
- 拿到本类所有的方法
method：clazz.getdeclaredmethods() - 排除掉静态方法和合成(issynthetic)方法
-
把每个method都转换成一个
constrainedexecutable装着~~(constrainedexecutable也是个constrainedelement)。在此期间它完成了如下事（方法和构造器都复杂点，因为包含入参和返回值）：
1. 找到方法上所有的注解保存起来
2. 处理入参、返回值（包括自动判断是作用在入参还是返回值上）检索constructor：getconstructormetadata( beanclass )
完全同处理method，略
检索type：getclasslevelconstraints( beanclass )
- 找打标注在此类上的所有的注解，转换成
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一把吧：==
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入群" 字样，会手动邀请入群
上一篇： 远程控制服务（SSH）之Linux环境下客户端与服务端的远程连接
下一篇： 数据库的数据类型