前言
前几篇文章在讲Spring的数据绑定的时候，多次提到过数据校验。可能有人认为数据校验模块并不是那么的重要，因为硬编码都可以做。若是这么想的话，那就大错特错了~
前面讲解DataBinder的时候一个小细节，它所在的包是：org.springframework.validation，并且在分析源码的时候能看到DataBinder它不仅能够完成数据绑定，也提供了对数据校验的支持且还保存了校验结果。
我以数据绑定DataBinder为引子引出了数据校验这一块，是想表明它的重要性。连Java都把它抽象成了JSR标准进行提出，so我认为这块是必修课，有必要了解本章的内容。
为什么要有数据校验？
数据校验 是非常常见的工作，在日常的开发中贯穿于代码的各个层次，从上层的View层到底层的数据层。
在此处有必要再强调一句：前面说了数据绑定并不属于Spring MVC的专利，同样的数据校验也不是只会发生在web层，它可以在任意一层，从后面的示例中你会有更深的理解
在任何时候，当你要处理一个应用程序的业务逻辑，数据校验是你必须要考虑和面对的事情。应用程序必须通过某种手段来确保输入进来的数据从语义上来讲是正确的（比如生日必须是过去时，年龄必须>0等等~）。
我们知道通常情况下程序肯定是分层的，不同的层一般由不同的人来开发。若你是一个有经验的程序员， 我相信你肯定见过在不同的层了都出现了相同的校验代码，这就是某种意义上的垃圾代码。
public String queryValueByKey(String parmTemplateCode, String conditionName, String conditionKey, String resultName) { checkNotNull(parmTemplateCode, "parmTemplateCode not null"); checkNotNull(conditionName, "conditionName not null"); checkNotNull(conditionKey, "conditionKey not null"); checkNotNull(resultName, "resultName not null"); ... }
从这个简单的方法入参校验至少能发现如下问题：
- 需要写大量的代码来进行参数验证。(这种代码多了就算垃圾代码)
- 需要通过注释来知道每个入参的约束是什么（否则别人咋看得懂）
- 每个程序员做参数验证的方式不一样，参数验证不通过抛出的异常也不一样（后期几乎没法维护）
如上会导致代码冗余和一些管理的问题（代码量越大，管理起来维护起来就越困难），比如说语义的一致性等。为了避免这样的情况发生，最好是将验证逻辑与相应的域模型（领域模型的概念）进行绑定，这就是本文提供的一个新思路（其实是JavaEE提供的思路）
为了解决这个问题，Bean Validation 为 JavaBean 验证定义了相应的元数据模型和 API。默认的元数据是 各种Java Annotations，当然也支持xml方式并且你也可以扩展~
可以说Bean Validation是JavaBean的一个拓展，它可以布局于任意一层代码，不局限于Web应用还是端应用。
Java Bean Validation
JSR是Java Specification Requests的缩写，意思是Java 规范提案。关于数据校验这块，最新的是JSR380，也就是我们常说的Bean Validation 2.0。
Bean Validation 2.0 是JSR第380号标准。该标准连接如下：https://www.jcp.org/en/egc/view?id=380
Bean Validation的主页：http://beanvalidation.org
Bean Validation的参考实现：https://github.com/hibernate/hibernate-validator
Bean Validation是一个通过配置注解来验证参数的框架，它包含两部分Bean Validation API（规范）和Hibernate Validator（实现）。
Bean Validation是Java定义的一套基于注解/xml的数据校验规范，目前已经从JSR 303的1.0版本升级到JSR 349的1.1版本，再到JSR 380的2.0版本（2.0完成于2017.08），已经经历了三个版本（我截图如下：）
现在绝大多数coder使用者其实都还在使用Bean Validation 1.1，毕竟一般来说它已经够用了~
本文会介绍Bean Validation 2.0提供的一些实用的新东西，毕竟Java8现在已成为主流，完全可以使用了~
简单Demo示例
要想使用它，首先就得导包嘛~根据经验，和JCache类似Java只提供了规范，并没有提供实现，所以我们可以先找到它的API包然后导入：
<dependency> <groupId>javax.validation</groupId> <artifactId>validation-api</artifactId> <!-- <version>1.1.0.Final</version> --> <version>2.0.1.Final</version> </dependency>
说明：2018年03月， Oracle 决定把 JavaEE 移交给开源组织 Eclipse 基金会，但是不希望 JavaEE 继续使用 Java 这个名字，尽管 Eclipse 做了争取，但是看来并没有什么用处。
所以最终：Java EE 正式改名为 Jakarta EE 了。 参考文章
这是它的新logo：
竟然已经捐献了，所以必然涉及到迁移，因此必然涉及到更名。以本文的JSR380规范为例：
JavaEE GAV：
<dependency> <groupId>javax.validation</groupId> <artifactId>validation-api</artifactId> <version>2.0.1.Final</version> </dependency>
迁移后为的GAV坐标为：
<dependency> <groupId>jakarta.validation</groupId> <artifactId>jakarta.validation-api</artifactId> <version>2.0.1</version> </dependency>
说明：hibernate-validator从6.1.x开始(2018年)，就全面拥抱jakarta啦，所以以后看到jakarta的坐标请不要觉得奇怪哦~
关于版本之间的差异其实不是本文说明的重点，毕竟2.0做到了很好的向下兼容，使用起来是无缝的。
但是本处还是给个1.1版本和2.0.1的截图，感官上简单对比一下区别：
兼容性表格
关于Bean Validation 2.0的关注点（新特性）
因为2.0推出的时间确实不算长，so此处我把一些重要的关注点列举如下：
1.对Java的最低版本要求是Java 8
2.支持容器的校验，通过TYPE_USE类型的注解实现对容器内容的约束：List<@Email String>
3.支持日期/时间的校验，@Past和@Future
4.拓展元数据（新增注解）：@Email，@NotEmpty，@NotBlank，@Positive， @PositiveOrZero，@Negative，@NegativeOrZero，@PastOrPresent和@FutureOrPresent
1. 像@Email、@NotEmpty、@NotBlank之前是Hibernate额外提供的，2.0标准后hibernate自动退位让贤并且标注为过期了
5.Bean Validation 2.0的唯一实现为Hibernate Validator。（其实还有Apache BVal，但是你懂的，forget it）
6.对于Hibernate Validator，它自己也扩展了一些注解支持。
1. 6.0以上版本新增(对应标准2.0版本)：@UniqueElements、@ISBN、@CodePointLength、、、、、、、、
2. 6.0以下版本可以使用的： @URL、@ScriptAssert、@SafeHtml、@Range、@ParameterScriptAssert、@Mod11Check、@Mod10Check、@LuhnCheck、@Length、@EAN、@Currency、@CreditCardNumber、@ConstraintComposition、@DurationMax、@DurationMin、**@REGON、@PESEL、@NIP、@TituloEleitoral、@CPF、@CNPJ**
3. Hibernate Validator默认会校验完所有的属性，然后返回所有的验证失败信息。开启fail fast mode后，只要有一个验证失败，则返回验证失败信息。
so，对于Java Bean Validation的实现落地产品就没啥好选的，导入Hibernate Validator(最新版本)吧：
<dependency> <groupId>org.hibernate.validator</groupId> <artifactId>hibernate-validator</artifactId> <version>6.0.17.Final</version> </dependency>
