吾皇一日不退役,爾等都是臣子
<center>對Spring感興趣可掃碼加入wx羣:Java高工、架構師3羣
(文末有二維碼)</center>java
前幾篇文章在講Spring的數據綁定的時候,屢次提到過數據校驗。可能有人認爲數據校驗模塊並非那麼的重要,由於硬編碼均可以作。如果這麼想的話,那就大錯特錯了~
前面講解DataBinder
的時候一個小細節,它所在的包是:org.springframework.validation
,而且在分析源碼的時候能看到DataBinder
它不只可以完成數據綁定,也提供了對數據校驗的支持且還保存了校驗結果。git
我以數據綁定DataBinder
爲引子引出了數據校驗這一塊,是想代表它的重要性。連Java都把它抽象成了JSR標準
進行提出,so我認爲這塊是必修課,有必要了解本章的內容。程序員
數據校驗 是很是常見的工做,在平常的開發中貫穿於代碼的各個層次,從上層的View層到底層的數據層。github
在此處有必要 再強調一句:前面說了數據綁定並不屬於Spring MVC的專利,一樣的數據校驗也不是隻會發生在web層, 它能夠在任意一層,從後面的示例中你會有更深的理解
在任什麼時候候,當你要處理一個應用程序的業務邏輯,數據校驗是你必須
要考慮和麪對的事情。應用程序必須經過某種手段來確保輸入進來的數據從語義上來說是正確的(好比生日必須是過去時,年齡必須>0等等~)。web
咱們知道一般狀況下程序確定是分層的,不一樣的層通常由不一樣的人來開發。若你是一個有經驗的程序員, 我相信你確定見過在不一樣的層了都出現了相同的校驗代碼,這就是某種意義上的垃圾代碼。spring
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"); ... }
從這個簡單的方法入參校驗至少能發現以下問題:apache
如上會致使代碼冗餘和一些管理的問題(代碼量越大,管理起來維護起來就越困難),好比說語義的一致性等。爲了不這樣的狀況發生,最好是將驗證邏輯與相應的域模型(領域模型的概念)進行綁定,這就是本文提供的一個新思路(實際上是JavaEE提供的思路)編程
爲了解決這個問題,Bean Validation
爲 JavaBean
驗證定義了相應的元數據模型和 API。默認的元數據是 各類Java Annotations
,固然也支持xml方式而且你也能夠擴展~
能夠說Bean Validation
是JavaBean
的一個拓展,它能夠佈局於任意一層代碼,不侷限於Web應用仍是端應用。api
JSR是Java Specification Requests
的縮寫,意思是Java 規範提案。關於數據校驗這塊,最新的是JSR380
,也就是咱們常說的Bean Validation 2.0
。緩存
Bean Validation 2.0 是JSR第380號標準。該標準鏈接以下: https://www.jcp.org/en/egc/vi...
Bean Validation的主頁: http://beanvalidation.org
Bean Validation的參考實現: https://github.com/hibernate/...
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如今已成爲主流,徹底可使用了~
要想使用它,首先就得導包嘛~根據經驗,和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>
關於版本之間的差別其實不是本文說明的重點,畢竟2.0作到了很好的向下兼容,使用起來是無縫的。
可是本處仍是給個1.1版本和2.0.1的截圖,感官上簡單對比一下區別:
Bean Validation | Hibernate Validation | JDK | Spring Boot |
---|---|---|---|
1.1 | 5.4 + | 6+ | 1.5.x |
2.0 | 6.0 + | 8+ | 2.0.x |
由於2.0推出的時間確實不算長,so此處我把一些重要的關注點列舉以下:
List<@Email String>
@Past
和@Future
拓展元數據(新增註解):@Email,@NotEmpty,@NotBlank,@Positive, @PositiveOrZero,@Negative,@NegativeOrZero,@PastOrPresent和@FutureOrPresent
1. 像`@Email、@NotEmpty、@NotBlank`以前是Hibernate額外提供的,2.0標準後hibernate自動退位讓賢而且標註爲過時了
Bean Validation 2.0
的惟一實現爲Hibernate Validator
。(其實還有Apache BVal
,可是你懂的,forget it)對於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、` 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>
==小細節:==
能夠看到,導入了hibernate-validator
就必要再本身導入Java Bean Validation
API了,所以建議不用再手動導入API,交給內部來管理依賴。
定義一個待校驗的普通JavaBean:
@Getter @Setter @ToString public class Person { // 錯誤消息message是能夠自定義的 @NotNull(message = "名字不能爲null") public String name; @Positive public Integer age; @NotNull @NotEmpty private List<@Email String> emails; @Future private Date start; }
書寫測試用例:
public static void main(String[] args) { Person person = new Person(); //person.setName("fsx"); person.setAge(-1); // 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)); //校驗經過 // 對person進行校驗而後拿到結果(顯然使用時默認的校驗器) 會保留下校驗失敗的消息 Set<ConstraintViolation<Person>> result = Validation.buildDefaultValidatorFactory().getValidator().validate(person); // 對結果進行遍歷輸出 result.stream().map(v -> v.getPropertyPath() + " " + v.getMessage() + ": " + v.getInvalidValue()) .forEach(System.out::println); }
運行,報錯啦:
Caused by: java.lang.ClassNotFoundException: javax.el.ELManager at java.net.URLClassLoader.findClass(URLClassLoader.java:382) ...
能夠看到運行必須依賴於javax.el
這個包。(其實我是比較費解的,爲什麼校驗框架非得依賴它呢?有小夥伴能夠幫忙解釋一下嗎?)
那行,導入依賴javax.el
以及它的實現:
<!-- 注意這裏導入的是Apr, 2013發佈的el3.x的版本,可是glassfish並無對此版本進行支持了 固然tomcat確定是支持的 --> <dependency> <groupId>javax.el</groupId> <artifactId>javax.el-api</artifactId> <version>3.0.1-b06</version> </dependency> <!-- servlet容器大都對el有實現(支持jsp的都對此有實現),好比tomcat/glassfish等 --> <dependency> <groupId>org.glassfish.web</groupId> <artifactId>javax.el</artifactId> <version>2.2.6</version> </dependency>
須要注意的是,網上大都建議導入
org.glassfish.web
包。可是EL3.0後它並無再提供支持了,
所以我我的是不建議使用它,而是使用下面tomcat的實現的~
關於EL的實現此處囉嗦一句:JavaEE並無提供el的實現,須要容器自行提供,好比上面你想要導入最爲流行的tomcat
,你能夠導入以下jar便可:
<!-- 嵌入式的tomcat --> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> <version>9.0.22</version> </dependency> <!-- 傳統的tomcat(須要注意的是:傳統的tomcat這種jar是不須要你手動導入的,tomcat自帶的) --> <dependency> <groupId>org.apache.tomcat</groupId> <artifactId>tomcat-jasper-el</artifactId> <version>9.0.22</version> <scope>provided</scope> </dependency>
此處還須要說明一點的是:嵌入式tomcat(好比SpringBoot環境)若要使用時須要顯示導入的。可是傳統tomcat中你若要使用是不用本身導入的(tomcat自帶此jar)。
可是,可是,可是自從tomcat8.5後再也不自帶jsper-el的包了,須要手動導入。(tomcat7仍是有的~)
==最佳實踐:==
通常來講,javax.el-api
以及validation-api
都是沒有必要單獨導入的,第三方包都會自帶。因此絕大數狀況下,咱們只須要這麼導入便可正常work,形以下面這樣很是趕忙整潔:
<dependency> <groupId>org.hibernate.validator</groupId> <artifactId>hibernate-validator</artifactId> <version>6.0.17.Final</version> </dependency> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> <version>9.0.22</version> </dependency>
答:那是由於絕大多數狀況下你使用@Valid是使用在Spring MVC上,它是不依賴於EL方式的,下篇文章會詳細說明關於數據校驗在Spring上的使用。而本文主要仍是講解API的方式~
通過一番導包後,再次運行打印以下(方式1、方式二結果一致):
name名字不能爲null: null // 此處錯誤消息是本身的自定義內容 age必須是正數: -1 emails[2].<list element>不是一個合法的電子郵件地址: aaa.com
這樣經過API調用的方式就完成了對這個JavaBean
的屬性校驗~
官方給它的定義爲:This class is the entry point for Bean Validation.
它做爲校驗的入口,有三種方式來啓動它:
最簡單方式:使用默認的ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
雖然是默認的單也會有以下2種狀況:
1. 若使用了xml配置了一個provider,那就會使用這個provider來提供Factory 2. 若沒有xml或者xml力沒有配置provider,那就是用默認的`ValidationProviderResolver`實現類來處理
ValidationProviderResolver
來跟XML配置邏輯選出一個ValidationProvider
來。大體代碼以下:Configuration configuration = Validation.byDefaultProvider() .providerResolver(new MyResolverStrategy()) // 自定義一個ValidationProviderResolver的實現類 .configure(); ValidatorFactory factory = configuration.buildValidatorFactory();
ValidationProvider
實現。好比HibernateValidator
就是一個ValidationProvider
的實現:HibernateValidatorConfiguration configuration = Validation.byProvider(HibernateValidator.class) // .providerResolver( ... ) // 由於制定了Provider,這個參數就可選了 .configure() .failFast(false); ValidatorFactory validatorFactory = configuration.buildValidatorFactory();
這三種初始化方式,在源碼處就是對應提供的三個public static
方法:
public class Validation { // 方式一 public static ValidatorFactory buildDefaultValidatorFactory() { return byDefaultProvider().configure().buildValidatorFactory(); } // 方式二 public static GenericBootstrap byDefaultProvider() { return new GenericBootstrapImpl(); } // 方式三 public static <T extends Configuration<T>, U extends ValidationProvider<T>> ProviderSpecificBootstrap<T> byProvider(Class<U> providerType) { return new ProviderSpecificBootstrapImpl<>( providerType ); } ... }
對於若你想使用xml文件獨立配置校驗規則,可使用Configuration.addMapping(new FileInputStream(validationFile));
,如今不多這麼使用,略~
使用注意事項:ValidatorFactory
被建立後應該緩存起來再提供使用,由於它是縣城安全的。
由於如今都會使用Hibernate-Validation
來處理校驗,所以此處只關心方式三~
HibernateValidatorConfiguration
此接口表示配置,繼承自標註接口javax.validation.Configuration
。很明顯,它是HibernateValidator
的專屬配置類
先看頂級接口:javax.validation.Configuration
,爲構建ValidatorFactory
的配置類。默認狀況下,它會讀取配置文件META-INF/validation.xml
,Configuration提供的API方法是覆蓋xml配置文件項的。若沒有找到validation.xml
,就會使用默認的ValidationProviderResolver
也就是:DefaultValidationProviderResolver
。
public interface Configuration<T extends Configuration<T>> { // 該方法調用後就不會再去找META-INF/validation.xml了 T ignoreXmlConfiguration(); // 消息內插器 它是個狠角色,關於它的使用場景,後續會有詳解(包括Spring都實現了它來作事) // 它的做用是:插入給定的約束衝突消息 T messageInterpolator(MessageInterpolator interpolator); // 肯定bean驗證提供程序是否能夠訪問屬性的協定。對每一個正在驗證或級聯的屬性調用此約定。(Spring木有實現它) // 對每一個正在驗證或級聯的屬性都會調用此約定 // Traversable: 可移動的 T traversableResolver(TraversableResolver resolver); // 建立ConstraintValidator的工廠 // ConstraintValidator:定義邏輯以驗證給定對象類型T的給定約束A。(A是個註解類型) T constraintValidatorFactory(ConstraintValidatorFactory constraintValidatorFactory); // ParameterNameProvider:提供Constructor/Method的方法名們 T parameterNameProvider(ParameterNameProvider parameterNameProvider); // java.time.Clock 用做斷定@Future和@Past(默認取值當前時間) // 若你但願他是個邏輯實現,提供一個它便可 // @since 2.0 T clockProvider(ClockProvider clockProvider); // 值提取器。這是add哦~ 負責從Optional、List等這種容器裏提取值~ // @since 2.0 T addValueExtractor(ValueExtractor<?> extractor); // 加載xml文件 T addMapping(InputStream stream); // 添加特定的屬性給Provider用的。此屬性等效於XML配置屬性。 // 此方法一般是框架本身分析xml文件獲得屬性值而後放進去,調用者通常不使用(固然也能夠用) T addProperty(String name, String value); // 下面都是get方法嘍 MessageInterpolator getDefaultMessageInterpolator(); TraversableResolver getDefaultTraversableResolver(); ConstraintValidatorFactory getDefaultConstraintValidatorFactory(); ParameterNameProvider getDefaultParameterNameProvider(); ClockProvider getDefaultClockProvider(); BootstrapConfiguration getBootstrapConfiguration(); // 整個配置也可返回出去 // 上面都是工做,這個方法纔是最終須要調用的:獲得一個ValidatorFactory ValidatorFactory buildValidatorFactory(); }
該接口提供了一些標準的配置項。在實際應用中都是使用Hibernate Validation
,因此再看看這個具體的子接口:
public interface HibernateValidatorConfiguration extends Configuration<HibernateValidatorConfiguration> { // 這批屬性,證實直接能夠經過System屬性值來控制,大大地方便~ // 這個機制快速失敗機制:true檢查完一個有錯誤就返回,false所有檢查完把錯誤消息一塊兒返回 默認false String FAIL_FAST = "hibernate.validator.fail_fast"; String ALLOW_PARAMETER_CONSTRAINT_OVERRIDE = "hibernate.validator.allow_parameter_constraint_override"; String ALLOW_MULTIPLE_CASCADED_VALIDATION_ON_RESULT = "hibernate.validator.allow_multiple_cascaded_validation_on_result"; String ALLOW_PARALLEL_METHODS_DEFINE_PARAMETER_CONSTRAINTS = "hibernate.validator.allow_parallel_method_parameter_constraint"; // @since 5.2 @Deprecated String CONSTRAINT_MAPPING_CONTRIBUTOR = "hibernate.validator.constraint_mapping_contributor"; // @since 5.3 String CONSTRAINT_MAPPING_CONTRIBUTORS = "hibernate.validator.constraint_mapping_contributors"; // @since 6.0.3 String ENABLE_TRAVERSABLE_RESOLVER_RESULT_CACHE = "hibernate.validator.enable_traversable_resolver_result_cache"; // @since 6.0.3 ScriptEvaluatorFactory:執行腳本 @Incubating String SCRIPT_EVALUATOR_FACTORY_CLASSNAME = "hibernate.validator.script_evaluator_factory"; // @since 6.0.5 comparing date/time in temporal constraints. In milliseconds. @Incubating String TEMPORAL_VALIDATION_TOLERANCE = "hibernate.validator.temporal_validation_tolerance"; // ResourceBundleMessageInterpolator用於 load resource bundles ResourceBundleLocator getDefaultResourceBundleLocator(); // 建立一個ConstraintMapping:經過編程API配置的約束映射 // 設置映射後,必須經過addMapping(constraintmapping)將其添加到此配置中。 ConstraintMapping createConstraintMapping(); // 拿到全部的值提取器 @since 6.0 @Incubating Set<ValueExtractor<?>> getDefaultValueExtractors(); // 往下就開始配置了~~~~~~~~~~ HibernateValidatorConfiguration addMapping(ConstraintMapping mapping); HibernateValidatorConfiguration failFast(boolean failFast); // used for loading user-provided resources: HibernateValidatorConfiguration externalClassLoader(ClassLoader externalClassLoader); // true:表示容許覆蓋約束的方法。false表示不予許(拋出異常) 默認值是false HibernateValidatorConfiguration allowOverridingMethodAlterParameterConstraint(boolean allow); // 定義是否容許對返回值標記多個約束以進行級聯驗證。 默認是false HibernateValidatorConfiguration allowMultipleCascadedValidationOnReturnValues(boolean allow); // 定義約束的**並行方法**是否應引起ConstraintDefinitionException HibernateValidatorConfiguration allowParallelMethodsDefineParameterConstraints(boolean allow); // 是否容許緩存TraversableResolver 默認值是true HibernateValidatorConfiguration enableTraversableResolverResultCache(boolean enabled); // 設置一個腳本執行器 @Incubating HibernateValidatorConfiguration scriptEvaluatorFactory(ScriptEvaluatorFactory scriptEvaluatorFactory); // 容許在時間約束中比較日期/時間時設置可接受的偏差範圍 // 好比@Past @PastOrPresent @Future @FutureOrPresent @Incubating HibernateValidatorConfiguration temporalValidationTolerance(Duration temporalValidationTolerance); // 容許設置將傳遞給約束驗證器的有效負載。若是屢次調用該方法,則只傳播最後傳遞的有效負載。 @Incubating HibernateValidatorConfiguration constraintValidatorPayload(Object constraintValidatorPayload); }
關於此接口的惟一實現類:ConfigurationImpl
,這裏就不用再作分析了,由於對於Validation
這塊,我們面向接口編程是徹底沒有問題的~
準備好了Configuration
後,下一步顯然就是configuration.buildValidatorFactory()
來獲得一個ValidatorFactory
嘍,關於ValidatorFactory
這塊的內容,請聽下文分解~
該文講解是關於Bean Validation
數據校驗,在如今Spring的高度封裝下,愈來愈少的人可以主動去發現Java實現/標準了~
實際上Spring
的強大並非本身創造了多少輪子,而是它主要是帶來了更爲簡單的抽象,從而減小樣板代碼、促進解耦、提升可單測性。所以對於有些經常使用的功能仍是建議稍微瞭解多一點,作到心中有數,運用起來也纔會更加的遊刃有餘
若文章格式混亂,可點擊
:
原文連接-原文連接-原文連接-原文連接-原文連接
==The last:若是以爲本文對你有幫助,不妨點個讚唄。固然分享到你的朋友圈讓更多小夥伴看到也是被做者本人許可的~
==
**若對技術內容感興趣能夠加入wx羣交流:Java高工、架構師3羣
。
若羣二維碼失效,請加wx號:fsx641385712
(或者掃描下方wx二維碼)。而且備註:"java入羣"
字樣,會手動邀請入羣**