原博客：https://blog.csdn.net/u013815546/article/details/77248003
前言
數據的校驗是交互式網站一個不可或缺的功能，前端的js校驗可以涵蓋大部分的校驗職責，如用戶名唯一性，生日格式，郵箱格式校驗等等常用的校驗。但是爲了避免用戶繞過瀏覽器，使用http工具直接向後端請求一些違法數據，服務端的數據校驗也是必要的，可以防止髒數據落到數據庫中，如果數據庫中出現一個非法的郵箱格式，也會讓運維人員頭疼不已。我在之前保險產品研發過程中，系統對數據校驗要求比較嚴格且追求可變性及效率，曾使用drools作爲規則引擎，兼任了校驗的功能。而在一般的應用，可以使用本文將要介紹的validation來對數據進行校驗。
簡述JSR303/JSR-349，hibernate validation，spring validation之間的關係。JSR303是一項標準,JSR-349是其的升級版本，添加了一些新特性，他們規定一些校驗規範即校驗註解，如@Null，@NotNull，@Pattern，他們位於javax.validation.constraints包下，只提供規範不提供實現。而hibernate validation是對這個規範的實踐（不要將hibernate和數據庫orm框架聯繫在一起），他提供了相應的實現，並增加了一些其他校驗註解，如@Email，@Length，@Range等等，他們位於org.hibernate.validator.constraints包下。而萬能的spring爲了給開發者提供便捷，對hibernate validation進行了二次封裝，顯示校驗validated bean時，你可以使用spring validation或者hibernate validation，而spring validation另一個特性，便是其在springmvc模塊中添加了自動校驗，並將校驗信息封裝進了特定的類中。這無疑便捷了我們的web開發。本文主要介紹在springmvc中自動校驗的機制。
引入依賴
我們使用maven構建springboot應用來進行demo演示。
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
我們只需要引入spring-boot-starter-web依賴即可，如果查看其子依賴，可以發現如下的依賴：
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
驗證了我之前的描述，web模塊使用了hibernate-validation，並且databind模塊也提供了相應的數據綁定功能。
構建啓動類
無需添加其他註解，一個典型的啓動類
@SpringBootApplication
public class ValidateApp {
public static void main(String[] args) {
SpringApplication.run(ValidateApp.class, args);
}
}
創建需要被校驗的實體類
public class Foo {
@NotBlank
private String name;
@Min(18)
private Integer age;
@Pattern(regexp = "^1(3|4|5|7|8)\\d{9}$",message = "手機號碼格式錯誤")
@NotBlank(message = "手機號碼不能爲空")
private String phone;
@Email(message = "郵箱格式錯誤")
private String email;
//... getter setter
}
使用一些比較常用的校驗註解，還是比較淺顯易懂的，字段上的註解名稱即可推斷出校驗內容，每一個註解都包含了message字段，用於校驗失敗時作爲提示信息，特殊的校驗註解，如Pattern（正則校驗），還可以自己添加正則表達式。
在@Controller中校驗數據
springmvc爲我們提供了自動封裝表單參數的功能，一個添加了參數校驗的典型controller如下所示。
@Controller
public class FooController {
@RequestMapping("/foo")
public String foo(@Validated Foo foo <1>, BindingResult bindingResult <2>) {
if(bindingResult.hasErrors()){
for (FieldError fieldError : bindingResult.getFieldErrors()) {
//...
}
return "fail";
}
return "success";
}
}
值得注意的地方：
<1> 參數Foo前需要加上@Validated註解，表明需要spring對其進行校驗，而校驗的信息會存放到其後的BindingResult中。注意，必須相鄰，如果有多個參數需要校驗，形式可以如下。foo(@Validated Foo foo, BindingResult fooBindingResult ，@Validated Bar bar, BindingResult barBindingResult);即一個校驗類對應一個校驗結果。
<2> 校驗結果會被自動填充，在controller中可以根據業務邏輯來決定具體的操作，如跳轉到錯誤頁面。
一個最基本的校驗就完成了，總結下框架已經提供了哪些校驗：
JSR提供的校驗註解：
@Null 被註釋的元素必須爲 null
@NotNull 被註釋的元素必須不爲 null
@AssertTrue 被註釋的元素必須爲 true
@AssertFalse 被註釋的元素必須爲 false
@Min(value) 被註釋的元素必須是一個數字，其值必須大於等於指定的最小值
@Max(value) 被註釋的元素必須是一個數字，其值必須小於等於指定的最大值
@DecimalMin(value) 被註釋的元素必須是一個數字，其值必須大於等於指定的最小值
@DecimalMax(value) 被註釋的元素必須是一個數字，其值必須小於等於指定的最大值
@Size(max=, min=) 被註釋的元素的大小必須在指定的範圍內
@Digits (integer, fraction) 被註釋的元素必須是一個數字，其值必須在可接受的範圍內
@Past 被註釋的元素必須是一個過去的日期
@Future 被註釋的元素必須是一個將來的日期
@Pattern(regex=,flag=) 被註釋的元素必須符合指定的正則表達式
Hibernate Validator提供的校驗註解：
@NotBlank(message =) 驗證字符串非null，且長度必須大於0
@Email 被註釋的元素必須是電子郵箱地址
@Length(min=,max=) 被註釋的字符串的大小必須在指定的範圍內
@NotEmpty 被註釋的字符串的必須非空
@Range(min=,max=,message=) 被註釋的元素必須在合適的範圍內
校驗實驗
我們對上面實現的校驗入口進行一次測試請求：
訪問 http://localhost:8080/foo?name=xujingfeng&email=000&age=19 可以得到如下的debug信息：
實驗告訴我們，校驗結果起了作用。並且，可以發現當發生多個錯誤，spring validation不會在第一個錯誤發生後立即停止，而是繼續試錯，告訴我們所有的錯誤。debug可以查看到更多豐富的錯誤信息，這些都是spring validation爲我們提供的便捷特性，基本適用於大多數場景。
你可能不滿足於簡單的校驗特性，下面進行一些補充。
分組校驗
如果同一個類，在不同的使用場景下有不同的校驗規則，那麼可以使用分組校驗。未成年人是不能喝酒的，而在其他場景下我們不做特殊的限制，這個需求如何體現同一個實體，不同的校驗規則呢？
改寫註解，添加分組：
Class Foo{
@Min(value = 18,groups = {Adult.class})
private Integer age;
public interface Adult{}
public interface Minor{}
}
這樣表明，只有在Adult分組下，18歲的限制纔會起作用。
Controller層改寫：
@RequestMapping("/drink")
public String drink(@Validated({Foo.Adult.class}) Foo foo, BindingResult bindingResult) {
if(bindingResult.hasErrors()){
for (FieldError fieldError : bindingResult.getFieldErrors()) {
//...
}
return "fail";
}
return "success";
}
@RequestMapping("/live")
public String live(@Validated Foo foo, BindingResult bindingResult) {
if(bindingResult.hasErrors()){
for (FieldError fieldError : bindingResult.getFieldErrors()) {
//...
}
return "fail";
}
return "success";
}
drink方法限定需要進行Adult校驗，而live方法則不做限制。
自定義校驗
業務需求總是比框架提供的這些簡單校驗要複雜的多，我們可以自定義校驗來滿足我們的需求。自定義spring validation非常簡單，主要分爲兩步。
1 自定義校驗註解
我們嘗試添加一個“字符串不能包含空格”的限制。
@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})
@Retention(RUNTIME)
@Documented
@Constraint(validatedBy = {CannotHaveBlankValidator.class})<1>
public @interface CannotHaveBlank {
//默認錯誤消息
String message() default "不能包含空格";
//分組
Class<?>[] groups() default {};
//負載
Class<? extends Payload>[] payload() default {};
//指定多個時使用
@Target({FIELD, METHOD, PARAMETER, ANNOTATION_TYPE})
@Retention(RUNTIME)
@Documented
@interface List {
CannotHaveBlank[] value();
}
}
我們不需要關注太多東西，使用spring validation的原則便是便捷我們的開發，例如payload，List ，groups，都可以忽略。
<1> 自定義註解中指定了這個註解真正的驗證者類。
2 編寫真正的校驗者類
public class CannotHaveBlankValidator implements <1> ConstraintValidator<CannotHaveBlank, String> {
@Override
public void initialize(CannotHaveBlank constraintAnnotation) {
}
@Override
public boolean isValid(String value, ConstraintValidatorContext context <2>) {
//null時不進行校驗
if (value != null && value.contains(" ")) {
<3>
//獲取默認提示信息
String defaultConstraintMessageTemplate = context.getDefaultConstraintMessageTemplate();
System.out.println("default message :" + defaultConstraintMessageTemplate);
//禁用默認提示信息
context.disableDefaultConstraintViolation();
//設置提示語
context.buildConstraintViolationWithTemplate("can not contains blank").addConstraintViolation();
return false;
}
return true;
}
}
<1> 所有的驗證者都需要實現ConstraintValidator接口，它的接口也很形象，包含一個初始化事件方法，和一個判斷是否合法的方法。
public interface ConstraintValidator<A extends Annotation, T> {
void initialize(A constraintAnnotation);
boolean isValid(T value, ConstraintValidatorContext context);
}
<2> ConstraintValidatorContext 這個上下文包含了認證中所有的信息，我們可以利用這個上下文實現獲取默認錯誤提示信息，禁用錯誤提示信息，改寫錯誤提示信息等操作。
<3> 一些典型校驗操作，或許可以對你產生啓示作用。
值得注意的一點是，自定義註解可以用在METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER之上，ConstraintValidator的第二個泛型參數T，是需要被校驗的類型。
手動校驗
可能在某些場景下需要我們手動校驗，即使用校驗器對需要被校驗的實體發起validate，同步獲得校驗結果。理論上我們既可以使用Hibernate Validation提供Validator，也可以使用Spring對其的封裝。在spring構建的項目中，提倡使用經過spring封裝過後的方法，這裏兩種方法都介紹下：
Hibernate Validation：
Foo foo = new Foo();
foo.setAge(22);
foo.setEmail("000");
ValidatorFactory vf = Validation.buildDefaultValidatorFactory();
Validator validator = vf.getValidator();
Set<ConstraintViolation<Foo>> set = validator.validate(foo);
for (ConstraintViolation<Foo> constraintViolation : set) {
System.out.println(constraintViolation.getMessage());
}
由於依賴了Hibernate Validation框架，我們需要調用Hibernate相關的工廠方法來獲取validator實例，從而校驗。
在spring framework文檔的Validation相關章節，可以看到如下的描述：
Spring provides full support for the Bean Validation API. This includes convenient support for bootstrapping a JSR-303/JSR-349 Bean Validation provider as a Spring bean. This allows for a javax.validation.ValidatorFactory or javax.validation.Validator to be injected wherever validation is needed in your application. Use the LocalValidatorFactoryBean to configure a default Validator as a Spring bean:
bean id=”validator” class=”org.springframework.validation.beanvalidation.LocalValidatorFactoryBean”
The basic configuration above will trigger Bean Validation to initialize using its default bootstrap mechanism. A JSR-303/JSR-349 provider, such as Hibernate Validator, is expected to be present in the classpath and will be detected automatically.
上面這段話主要描述了spring對validation全面支持JSR-303、JSR-349的標準，並且封裝了LocalValidatorFactoryBean作爲validator的實現。值得一提的是，這個類的責任其實是非常重大的，他兼容了spring的validation體系和hibernate的validation體系，也可以被開發者直接調用，代替上述的從工廠方法中獲取的hibernate validator。由於我們使用了springboot，會觸發web模塊的自動配置，LocalValidatorFactoryBean已經成爲了Validator的默認實現，使用時只需要自動注入即可。
@Autowired
Validator globalValidator; <1>
@RequestMapping("/validate")
public String validate() {
Foo foo = new Foo();
foo.setAge(22);
foo.setEmail("000");
Set<ConstraintViolation<Foo>> set = globalValidator.validate(foo);<2>
for (ConstraintViolation<Foo> constraintViolation : set) {
System.out.println(constraintViolation.getMessage());
}
return "success";
}
<1> 真正使用過Validator接口的讀者會發現有兩個接口，一個是位於javax.validation包下，另一個位於org.springframework.validation包下，注意我們這裏使用的是前者javax.validation，後者是spring自己內置的校驗接口，LocalValidatorFactoryBean同時實現了這兩個接口。
<2> 此處校驗接口最終的實現類便是LocalValidatorFactoryBean。
基於方法校驗
@RestController
@Validated <1>
public class BarController {
@RequestMapping("/bar")
public @NotBlank <2> String bar(@Min(18) Integer age <3>) {
System.out.println("age : " + age);
return "";
}
@ExceptionHandler(ConstraintViolationException.class)
public Map handleConstraintViolationException(ConstraintViolationException cve){
Set<ConstraintViolation<?>> cves = cve.getConstraintViolations();<4>
for (ConstraintViolation<?> constraintViolation : cves) {
System.out.println(constraintViolation.getMessage());
}
Map map = new HashMap();
map.put("errorCode",500);
return map;
}
}
<1> 爲類添加@Validated註解
<2> <3> 校驗方法的返回值和入參
<4> 添加一個異常處理器，可以獲得沒有通過校驗的屬性相關信息
基於方法的校驗，個人不推薦使用，感覺和項目結合的不是很好。
使用校驗框架的一些想法
理論上spring validation可以實現很多複雜的校驗，你甚至可以使你的Validator獲取ApplicationContext，獲取spring容器中所有的資源，進行諸如數據庫校驗，注入其他校驗工具，完成組合校驗（如前後密碼一致）等等操作，但是尋求一個易用性和封裝複雜性之間的平衡點是我們作爲工具使用者應該考慮的，我推崇的方式，是僅僅使用自帶的註解和自定義註解，完成一些簡單的，可複用的校驗。而對於複雜的校驗，則包含在業務代碼之中，畢竟如用戶名是否存在這樣的校驗，僅僅依靠數據庫查詢還不夠，爲了避免併發問題，還是得加上唯一索引之類的額外工作，不是嗎？