資訊專(zhuān)欄INFORMATION COLUMN
摘要：可能有人認(rèn)為數(shù)據(jù)校驗(yàn)?zāi)K并不是那么的重要，因?yàn)橛簿幋a都可以做。我以數(shù)據(jù)綁定為引子引出了數(shù)據(jù)校驗(yàn)這一塊，是想表明它的重要性。關(guān)于數(shù)據(jù)校驗(yàn)這塊，最新的是，也就是我們常說(shuō)的。
每篇一句
吾皇一日不退役，爾等都是臣子
前幾篇文章在講Spring的數(shù)據(jù)綁定的時(shí)候，多次提到過(guò)數(shù)據(jù)校驗(yàn)?？赡苡腥苏J(rèn)為數(shù)據(jù)校驗(yàn)?zāi)K并不是那么的重要，因?yàn)橛簿幋a都可以做。若是這么想的話，那就大錯(cuò)特錯(cuò)了~
前面講解DataBinder的時(shí)候一個(gè)小細(xì)節(jié)，它所在的包是：org.springframework.validation，并且在分析源碼的時(shí)候能看到DataBinder它不僅能夠完成數(shù)據(jù)綁定，也提供了對(duì)數(shù)據(jù)校驗(yàn)的支持且還保存了校驗(yàn)結(jié)果。
我以數(shù)據(jù)綁定DataBinder為引子引出了數(shù)據(jù)校驗(yàn)這一塊，是想表明它的重要性。連Java都把它抽象成了JSR標(biāo)準(zhǔn)進(jìn)行提出，so我認(rèn)為這塊是必修課，有必要了解本章的內(nèi)容。
為什么要有數(shù)據(jù)校驗(yàn)？數(shù)據(jù)校驗(yàn) 是非常常見(jiàn)的工作，在日常的開(kāi)發(fā)中貫穿于代碼的各個(gè)層次，從上層的View層到底層的數(shù)據(jù)層。
在此處有必要再?gòu)?qiáng)調(diào)一句：前面說(shuō)了數(shù)據(jù)綁定并不屬于Spring MVC的專(zhuān)利，同樣的數(shù)據(jù)校驗(yàn)也不是只會(huì)發(fā)生在web層，它可以在任意一層，從后面的示例中你會(huì)有更深的理解
在任何時(shí)候，當(dāng)你要處理一個(gè)應(yīng)用程序的業(yè)務(wù)邏輯，數(shù)據(jù)校驗(yàn)是你必須要考慮和面對(duì)的事情。應(yīng)用程序必須通過(guò)某種手段來(lái)確保輸入進(jìn)來(lái)的數(shù)據(jù)從語(yǔ)義上來(lái)講是正確的（比如生日必須是過(guò)去時(shí)，年齡必須>0等等~）。
我們知道通常情況下程序肯定是分層的，不同的層一般由不同的人來(lái)開(kāi)發(fā)。若你是一個(gè)有經(jīng)驗(yàn)的程序員， 我相信你肯定見(jiàn)過(guò)在不同的層了都出現(xiàn)了相同的校驗(yàn)代碼，這就是某種意義上的垃圾代碼。
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");
...
}
從這個(gè)簡(jiǎn)單的方法入?yún)⑿ｒ?yàn)至少能發(fā)現(xiàn)如下問(wèn)題：
需要寫(xiě)大量的代碼來(lái)進(jìn)行參數(shù)驗(yàn)證。(這種代碼多了就算垃圾代碼)
需要通過(guò)注釋來(lái)知道每個(gè)入?yún)⒌募s束是什么（否則別人咋看得懂）
每個(gè)程序員做參數(shù)驗(yàn)證的方式不一樣，參數(shù)驗(yàn)證不通過(guò)拋出的異常也不一樣（后期幾乎沒(méi)法維護(hù)）
如上會(huì)導(dǎo)致代碼冗余和一些管理的問(wèn)題（代碼量越大，管理起來(lái)維護(hù)起來(lái)就越困難），比如說(shuō)語(yǔ)義的一致性等。為了避免這樣的情況發(fā)生，最好是將驗(yàn)證邏輯與相應(yīng)的域模型（領(lǐng)域模型的概念）進(jìn)行綁定，這就是本文提供的一個(gè)新思路（其實(shí)是JavaEE提供的思路）
為了解決這個(gè)問(wèn)題，Bean Validation 為 JavaBean 驗(yàn)證定義了相應(yīng)的元數(shù)據(jù)模型和 API。默認(rèn)的元數(shù)據(jù)是 各種Java Annotations，當(dāng)然也支持xml方式并且你也可以擴(kuò)展~
可以說(shuō)Bean Validation是JavaBean的一個(gè)拓展，它可以布局于任意一層代碼，不局限于Web應(yīng)用還是端應(yīng)用。
JSR是Java Specification Requests的縮寫(xiě)，意思是Java 規(guī)范提案。關(guān)于數(shù)據(jù)校驗(yàn)這塊，最新的是JSR380，也就是我們常說(shuō)的Bean Validation 2.0。
Bean Validation 2.0 是JSR第380號(hào)標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)連接如下：https://www.jcp.org/en/egc/vi...
Bean Validation的主頁(yè)：http://beanvalidation.org
Bean Validation的參考實(shí)現(xiàn)：https://github.com/hibernate/...
Bean Validation是一個(gè)通過(guò)配置注解來(lái)驗(yàn)證參數(shù)的框架，它包含兩部分Bean Validation API（規(guī)范）和Hibernate Validator（實(shí)現(xiàn)）。
Bean Validation是Java定義的一套基于注解/xml的數(shù)據(jù)校驗(yàn)規(guī)范，目前已經(jīng)從JSR 303的1.0版本升級(jí)到JSR 349的1.1版本，再到JSR 380的2.0版本（2.0完成于2017.08），已經(jīng)經(jīng)歷了三個(gè)版本（我截圖如下：）
現(xiàn)在絕大多數(shù)coder使用者其實(shí)都還在使用Bean Validation 1.1，畢竟一般來(lái)說(shuō)它已經(jīng)夠用了~
本文會(huì)介紹Bean Validation 2.0提供的一些實(shí)用的新東西，畢竟Java8現(xiàn)在已成為主流，完全可以使用了~
要想使用它，首先就得導(dǎo)包嘛~根據(jù)經(jīng)驗(yàn)，和JCache類(lèi)似Java只提供了規(guī)范，并沒(méi)有提供實(shí)現(xiàn)，所以我們可以先找到它的API包然后導(dǎo)入：
javax.validation validation-api 2.0.1.Final
關(guān)于版本之間的差異其實(shí)不是本文說(shuō)明的重點(diǎn)，畢竟2.0做到了很好的向下兼容，使用起來(lái)是無(wú)縫的。
但是本處還是給個(gè)1.1版本和2.0.1的截圖，感官上簡(jiǎn)單對(duì)比一下區(qū)別：
| Bean Validation | Hibernate Validation | JDK | Spring Boot |
|---|---|---|---|
| 1.1 | 5.4 + | 6+ | 1.5.x |
| 2.0 | 6.0 + | 8+ | 2.0.x |
因?yàn)?.0推出的時(shí)間確實(shí)不算長(zhǎng)，so此處我把一些重要的關(guān)注點(diǎn)列舉如下：
對(duì)Java的最低版本要求是Java 8
支持容器的校驗(yàn)，通過(guò)TYPE_USE類(lèi)型的注解實(shí)現(xiàn)對(duì)容器內(nèi)容的約束：List<@Email String>
支持日期/時(shí)間的校驗(yàn)，@Past和@Future
拓展元數(shù)據(jù)（新增注解）：@Email，@NotEmpty，@NotBlank，@Positive， @PositiveOrZero，@Negative，@NegativeOrZero，@PastOrPresent和@FutureOrPresent
1. 像`@Email、@NotEmpty、@NotBlank`之前是Hibernate額外提供的，2.0標(biāo)準(zhǔn)后hibernate自動(dòng)退位讓賢并且標(biāo)注為過(guò)期了
Bean Validation 2.0的唯一實(shí)現(xiàn)為Hibernate Validator。（其實(shí)還有Apache BVal，但是你懂的，forget it）
對(duì)于Hibernate Validator，它自己也擴(kuò)展了一些注解支持。
1. **6.0以上**版本新增(對(duì)應(yīng)標(biāo)準(zhǔn)2.0版本)：`@UniqueElements、@ISBN、@CodePointLength`
2. **6.0以下**版本可以使用的： `@URL、@ScriptAssert、@SafeHtml、@Range、@ParameterScriptAssert、@Mod11Check、@Mod10Check、@LuhnCheck、@Length、@EAN、@Currency、@CreditCardNumber、@ConstraintComposition、`
3. `Hibernate Validator`默認(rèn)會(huì)校驗(yàn)完所有的屬性，然后**返回所有的**驗(yàn)證`失敗信息`。開(kāi)啟fail fast mode后，只要有一個(gè)驗(yàn)證失敗，則返回驗(yàn)證失敗信息。
so，對(duì)于Java Bean Validation的實(shí)現(xiàn)落地產(chǎn)品就沒(méi)啥好選的，導(dǎo)入Hibernate Validator(最新版本)吧：
org.hibernate.validator hibernate-validator 6.0.17.Final
==小細(xì)節(jié)：==
可以看到，導(dǎo)入了hibernate-validator就必要再自己導(dǎo)入Java Bean ValidationAPI了，因此建議不用再手動(dòng)導(dǎo)入API，交給內(nèi)部來(lái)管理依賴(lài)。
定義一個(gè)待校驗(yàn)的普通JavaBean：
@Getter
@Setter
@ToString
public class Person {
// 錯(cuò)誤消息message是可以自定義的
@NotNull(message = "名字不能為null")
public String name;
@Positive
public Integer age;
@NotNull
@NotEmpty
private List<@Email String> emails;
@Future
private Date start;
}
書(shū)寫(xiě)測(cè)試用例：
public static void main(String[] args) {
Person person = new Person();
//person.setName("fsx");
person.setAge(-1);
// email校驗(yàn)：雖然是List都可以校驗(yàn)哦
person.setEmails(Arrays.asList("fsx@gmail.com", "baidu@baidu.com", "aaa.com"));
//person.setStart(new Date()); //start 需要是一個(gè)將來(lái)的時(shí)間: Sun Jul 21 10:45:03 CST 2019
//person.setStart(new Date(System.currentTimeMillis() + 10000)); //校驗(yàn)通過(guò)
// 對(duì)person進(jìn)行校驗(yàn)然后拿到結(jié)果（顯然使用時(shí)默認(rèn)的校驗(yàn)器） 會(huì)保留下校驗(yàn)失敗的消息
Set> result = Validation.buildDefaultValidatorFactory().getValidator().validate(person);
// 對(duì)結(jié)果進(jìn)行遍歷輸出
result.stream().map(v -> v.getPropertyPath() + " " + v.getMessage() + ": " + v.getInvalidValue())
.forEach(System.out::println);
}
運(yùn)行，報(bào)錯(cuò)啦：
Caused by: java.lang.ClassNotFoundException: javax.el.ELManager
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
...
可以看到運(yùn)行必須依賴(lài)于javax.el這個(gè)包。（其實(shí)我是比較費(fèi)解的，為何校驗(yàn)框架非得依賴(lài)它呢？有小伙伴可以幫忙解釋一下嗎？）
那行，導(dǎo)入依賴(lài)javax.el以及它的實(shí)現(xiàn)：
javax.el javax.el-api 3.0.1-b06 org.glassfish.web javax.el 2.2.6
需要注意的是，網(wǎng)上大都建議導(dǎo)入org.glassfish.web包。但是EL3.0后它并沒(méi)有再提供支持了，因此我個(gè)人是不建議使用它，而是使用下面tomcat的實(shí)現(xiàn)的~
關(guān)于EL的實(shí)現(xiàn)此處啰嗦一句：JavaEE并沒(méi)有提供el的實(shí)現(xiàn)，需要容器自行提供，比如上面你想要導(dǎo)入最為流行的tomcat，你可以導(dǎo)入如下jar即可：
org.apache.tomcat.embed tomcat-embed-el 9.0.22 org.apache.tomcat tomcat-jasper-el 9.0.22 provided
此處還需要說(shuō)明一點(diǎn)的是：嵌入式tomcat（比如SpringBoot環(huán)境）若要使用時(shí)需要顯示導(dǎo)入的。但是傳統(tǒng)tomcat中你若要使用是不用自己導(dǎo)入的（tomcat自帶此jar）。
但是，但是，但是自從tomcat8.5后不再自帶jsper-el的包了，需要手動(dòng)導(dǎo)入。（tomcat7還是有的~）
==最佳實(shí)踐：==
一般來(lái)說(shuō)，javax.el-api以及validation-api都是沒(méi)有必要多帶帶導(dǎo)入的，第三方包都會(huì)自帶。所以絕大數(shù)情況下，我們只需要這么導(dǎo)入即可正常work，形如下面這樣非常趕緊整潔：
org.hibernate.validator hibernate-validator 6.0.17.Final org.apache.tomcat.embed tomcat-embed-el 9.0.22
答：那是因?yàn)榻^大多數(shù)情況下你使用@Valid是使用在Spring MVC上，它是不依賴(lài)于EL方式的，下篇文章會(huì)詳細(xì)說(shuō)明關(guān)于數(shù)據(jù)校驗(yàn)在Spring上的使用。而本文主要還是講解API的方式~
經(jīng)過(guò)一番導(dǎo)包后，再次運(yùn)行打印如下（方式一、方式二結(jié)果一致）：
name名字不能為null: null // 此處錯(cuò)誤消息是自己的自定義內(nèi)容 age必須是正數(shù): -1 emails[2].不是一個(gè)合法的電子郵件地址: aaa.com
這樣通過(guò)API調(diào)用的方式就完成了對(duì)這個(gè)JavaBean的屬性校驗(yàn)~
核心API分析 Validation官方給它的定義為：This class is the entry point for Bean Validation.它作為校驗(yàn)的入口，有三種方式來(lái)啟動(dòng)它：
最簡(jiǎn)單方式：使用默認(rèn)的ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); 雖然是默認(rèn)的單也會(huì)有如下2種情況：
1. 若使用了xml配置了一個(gè)provider，那就會(huì)使用這個(gè)provider來(lái)提供Factory
2. 若沒(méi)有xml或者xml力沒(méi)有配置provider，那就是用默認(rèn)的`ValidationProviderResolver`實(shí)現(xiàn)類(lèi)來(lái)處理
方式二：選擇自定義的ValidationProviderResolver來(lái)跟XML配置邏輯選出一個(gè)ValidationProvider來(lái)。大致代碼如下：
Configuration configuration = Validation.byDefaultProvider()
.providerResolver(new MyResolverStrategy()) // 自定義一個(gè)ValidationProviderResolver的實(shí)現(xiàn)類(lèi)
.configure();
ValidatorFactory factory = configuration.buildValidatorFactory();
第三種方式就更加自由了：你可以直接提供一個(gè)類(lèi)型安全的ValidationProvider實(shí)現(xiàn)。比如HibernateValidator就是一個(gè)ValidationProvider的實(shí)現(xiàn)：
HibernateValidatorConfiguration configuration = Validation.byProvider(HibernateValidator.class)
// .providerResolver( ... ) // 因?yàn)橹贫薖rovider，這個(gè)參數(shù)就可選了
.configure()
.failFast(false);
ValidatorFactory validatorFactory = configuration.buildValidatorFactory();
這三種初始化方式，在源碼處就是對(duì)應(yīng)提供的三個(gè)public static方法：
public class Validation {
// 方式一
public static ValidatorFactory buildDefaultValidatorFactory() {
return byDefaultProvider().configure().buildValidatorFactory();
}
// 方式二
public static GenericBootstrap byDefaultProvider() {
return new GenericBootstrapImpl();
}
// 方式三
public static , U extends ValidationProvider> ProviderSpecificBootstrap byProvider(Class providerType) {
return new ProviderSpecificBootstrapImpl<>( providerType );
}
...
}
對(duì)于若你想使用xml文件獨(dú)立配置校驗(yàn)規(guī)則，可以使用Configuration.addMapping(new FileInputStream(validationFile));，現(xiàn)在很少這么使用，略~
使用注意事項(xiàng)：ValidatorFactory被創(chuàng)建后應(yīng)該緩存起來(lái)再提供使用，因?yàn)樗强h城安全的。
因?yàn)楝F(xiàn)在都會(huì)使用Hibernate-Validation來(lái)處理校驗(yàn)，因此此處只關(guān)心方式三~
HibernateValidatorConfiguration此接口表示配置，繼承自標(biāo)注接口javax.validation.Configuration。很明顯，它是HibernateValidator的專(zhuān)屬配置類(lèi)
先看頂級(jí)接口：javax.validation.Configuration，為構(gòu)建ValidatorFactory的配置類(lèi)。默認(rèn)情況下，它會(huì)讀取配置文件META-INF/validation.xml，Configuration提供的API方法是覆蓋xml配置文件項(xiàng)的。若沒(méi)有找到validation.xml，就會(huì)使用默認(rèn)的ValidationProviderResolver也就是：DefaultValidationProviderResolver。
public interface Configuration> { // 該方法調(diào)用后就不會(huì)再去找META-INF/validation.xml了 T ignoreXmlConfiguration(); // 消息內(nèi)插器 它是個(gè)狠角色，關(guān)于它的使用場(chǎng)景，后續(xù)會(huì)有詳解（包括Spring都實(shí)現(xiàn)了它來(lái)做事） // 它的作用是：插入給定的約束沖突消息 T messageInterpolator(MessageInterpolator interpolator); // 確定bean驗(yàn)證提供程序是否可以訪問(wèn)屬性的協(xié)定。對(duì)每個(gè)正在驗(yàn)證或級(jí)聯(lián)的屬性調(diào)用此約定。（Spring木有實(shí)現(xiàn)它） // 對(duì)每個(gè)正在驗(yàn)證或級(jí)聯(lián)的屬性都會(huì)調(diào)用此約定 // Traversable： 可移動(dòng)的 T traversableResolver(TraversableResolver resolver); // 創(chuàng)建ConstraintValidator的工廠 // ConstraintValidator：定義邏輯以驗(yàn)證給定對(duì)象類(lèi)型T的給定約束A。(A是個(gè)注解類(lèi)型) T constraintValidatorFactory(ConstraintValidatorFactory constraintValidatorFactory); // ParameterNameProvider：提供Constructor/Method的方法名們 T parameterNameProvider(ParameterNameProvider parameterNameProvider); // java.time.Clock 用作判定@Future和@Past（默認(rèn)取值當(dāng)前時(shí)間） // 若你希望他是個(gè)邏輯實(shí)現(xiàn)，提供一個(gè)它即可 // @since 2.0 T clockProvider(ClockProvider clockProvider); // 值提取器。這是add哦~ 負(fù)責(zé)從Optional、List等這種容器里提取值~ // @since 2.0 T addValueExtractor(ValueExtractor extractor); // 加載xml文件 T addMapping(InputStream stream); // 添加特定的屬性給Provider用的。此屬性等效于XML配置屬性。 // 此方法通常是框架自己分析xml文件得到屬性值然后放進(jìn)去，調(diào)用者一般不使用（當(dāng)然也可以用） T addProperty(String name, String value); // 下面都是get方法嘍 MessageInterpolator getDefaultMessageInterpolator(); TraversableResolver getDefaultTraversableResolver(); ConstraintValidatorFactory getDefaultConstraintValidatorFactory(); ParameterNameProvider getDefaultParameterNameProvider(); ClockProvider getDefaultClockProvider(); BootstrapConfiguration getBootstrapConfiguration(); // 整個(gè)配置也可返回出去 // 上面都是工作，這個(gè)方法才是最終需要調(diào)用的：得到一個(gè)ValidatorFactory ValidatorFactory buildValidatorFactory(); }
該接口提供了一些標(biāo)準(zhǔn)的配置項(xiàng)。在實(shí)際應(yīng)用中都是使用Hibernate Validation，所以再看看這個(gè)具體的子接口：
