前言

數(shù)據(jù)的校驗是交互式網(wǎng)站一個不可或缺的功能，前端的js校驗可以涵蓋大部分的校驗職責，如用戶名唯一性，生日格式，郵箱格式校驗等等常用的校驗。但是為了避免用戶繞過瀏覽器，使用http工具直接向后端請求一些違法數(shù)據(jù)，服務端的數(shù)據(jù)校驗也是必要的，可以防止臟數(shù)據(jù)落到數(shù)據(jù)庫中，如果數(shù)據(jù)庫中出現(xiàn)一個非法的郵箱格式，也會讓運維人員頭疼不已。我在之前保險產(chǎn)品研發(fā)過程中，系統(tǒng)對數(shù)據(jù)校驗要求比較嚴格且追求可變性及效率，曾使用drools作為規(guī)則引擎，兼任了校驗的功能。而在一般的應用，可以使用本文將要介紹的validation來對數(shù)據(jù)進行校驗。

簡述JSR303/JSR-349，hibernate validation，spring validation之間的關(guān)系。JSR303是一項標準,JSR-349是其的升級版本，添加了一些新特性，他們規(guī)定一些校驗規(guī)范即校驗注解，如@Null，@NotNull，@Pattern，他們位于javax.validation.constraints包下，只提供規(guī)范不提供實現(xiàn)。而hibernate validation是對這個規(guī)范的實踐（不要將hibernate和數(shù)據(jù)庫orm框架聯(lián)系在一起），他提供了相應的實現(xiàn)，并增加了一些其他校驗注解，如@Email，@Length，@Range等等，他們位于org.hibernate.validator.constraints包下。而萬能的spring為了給開發(fā)者提供便捷，對hibernate validation進行了二次封裝，顯示校驗validated bean時，你可以使用spring validation或者hibernate validation，而spring validation另一個特性，便是其在springmvc模塊中添加了自動校驗，并將校驗信息封裝進了特定的類中。這無疑便捷了我們的web開發(fā)。本文主要介紹在springmvc中自動校驗的機制。

引入依賴

我們使用maven構(gòu)建springboot應用來進行demo演示。

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

我們只需要引入spring-boot-starter-web依賴即可，如果查看其子依賴，可以發(fā)現(xiàn)如下的依賴：

<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模塊也提供了相應的數(shù)據(jù)綁定功能。

構(gòu)建啟動類

無需添加其他注解，一個典型的啟動類

@SpringBootApplication
public class ValidateApp {

  public static void main(String[] args) {
    SpringApplication.run(ValidateApp.class, args);
  }
}

創(chuàng)建需要被校驗的實體類

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

}

使用一些比較常用的校驗注解，還是比較淺顯易懂的，字段上的注解名稱即可推斷出校驗內(nèi)容，每一個注解都包含了message字段，用于校驗失敗時作為提示信息，特殊的校驗注解，如Pattern（正則校驗），還可以自己添加正則表達式。

在@Controller中校驗數(shù)據(jù)

springmvc為我們提供了自動封裝表單參數(shù)的功能，一個添加了參數(shù)校驗的典型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> 參數(shù)Foo前需要加上@Validated注解，表明需要spring對其進行校驗，而校驗的信息會存放到其后的BindingResult中。注意，必須相鄰，如果有多個參數(shù)需要校驗，形式可以如下。foo(@Validated Foo foo, BindingResult fooBindingResult ，@Validated Bar bar, BindingResult barBindingResult);即一個校驗類對應一個校驗結(jié)果。

<2> 校驗結(jié)果會被自動填充，在controller中可以根據(jù)業(yè)務邏輯來決定具體的操作，如跳轉(zhuǎn)到錯誤頁面。

一個最基本的校驗就完成了，總結(jié)下框架已經(jīng)提供了哪些校驗：

JSR提供的校驗注解：
@Null 被注釋的元素必須為 null
@NotNull 被注釋的元素必須不為 null
@AssertTrue 被注釋的元素必須為 true
@AssertFalse 被注釋的元素必須為 false
@Min(value) 被注釋的元素必須是一個數(shù)字，其值必須大于等于指定的最小值
@Max(value) 被注釋的元素必須是一個數(shù)字，其值必須小于等于指定的最大值
@DecimalMin(value) 被注釋的元素必須是一個數(shù)字，其值必須大于等于指定的最小值
@DecimalMax(value) 被注釋的元素必須是一個數(shù)字，其值必須小于等于指定的最大值
@Size(max=, min=) 被注釋的元素的大小必須在指定的范圍內(nèi)
@Digits (integer, fraction) 被注釋的元素必須是一個數(shù)字，其值必須在可接受的范圍內(nèi)
@Past 被注釋的元素必須是一個過去的日期
@Future 被注釋的元素必須是一個將來的日期
@Pattern(regex=,flag=) 被注釋的元素必須符合指定的正則表達式

Hibernate Validator提供的校驗注解：
@NotBlank(message =) 驗證字符串非null，且長度必須大于0
@Email 被注釋的元素必須是電子郵箱地址
@Length(min=,max=) 被注釋的字符串的大小必須在指定的范圍內(nèi)
@NotEmpty 被注釋的字符串的必須非空
@Range(min=,max=,message=) 被注釋的元素必須在合適的范圍內(nèi)

校驗實驗

我們對上面實現(xiàn)的校驗入口進行一次測試請求：

訪問 http://localhost:8080/foo?name=xujingfeng&email=000&age=19 可以得到如下的debug信息：

實驗告訴我們，校驗結(jié)果起了作用。并且，可以發(fā)現(xiàn)當發(fā)生多個錯誤，spring validation不會在第一個錯誤發(fā)生后立即停止，而是繼續(xù)試錯，告訴我們所有的錯誤。debug可以查看到更多豐富的錯誤信息，這些都是spring validation為我們提供的便捷特性，基本適用于大多數(shù)場景。

你可能不滿足于簡單的校驗特性，下面進行一些補充。

分組校驗

如果同一個類，在不同的使用場景下有不同的校驗規(guī)則，那么可以使用分組校驗。未成年人是不能喝酒的，而在其他場景下我們不做特殊的限制，這個需求如何體現(xiàn)同一個實體，不同的校驗規(guī)則呢？

改寫注解，添加分組：

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方法則不做限制。

自定義校驗

業(yè)務需求總是比框架提供的這些簡單校驗要復雜的多，我們可以自定義校驗來滿足我們的需求。自定義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();
  }

}

我們不需要關(guān)注太多東西，使用spring validation的原則便是便捷我們的開發(fā)，例如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();
      //設(shè)置提示語
      context.buildConstraintViolationWithTemplate("can not contains blank").addConstraintViolation();
      return false;
    }
    return true;
  }
}

<1> 所有的驗證者都需要實現(xiàn)ConstraintValidator接口，它的接口也很形象，包含一個初始化事件方法，和一個判斷是否合法的方法。

public interface ConstraintValidator<A extends Annotation, T> {

  void initialize(A constraintAnnotation);

  boolean isValid(T value, ConstraintValidatorContext context);
}

<2> ConstraintValidatorContext 這個上下文包含了認證中所有的信息，我們可以利用這個上下文實現(xiàn)獲取默認錯誤提示信息，禁用錯誤提示信息，改寫錯誤提示信息等操作。

<3> 一些典型校驗操作，或許可以對你產(chǎn)生啟示作用。

值得注意的一點是，自定義注解可以用在METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER之上，ConstraintValidator的第二個泛型參數(shù)T，是需要被校驗的類型。

手動校驗

可能在某些場景下需要我們手動校驗，即使用校驗器對需要被校驗的實體發(fā)起validate，同步獲得校驗結(jié)果。理論上我們既可以使用Hibernate Validation提供Validator，也可以使用Spring對其的封裝。在spring構(gòu)建的項目中，提倡使用經(jīng)過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框架，我們需要調(diào)用Hibernate相關(guān)的工廠方法來獲取validator實例，從而校驗。

在spring framework文檔的Validation相關(guān)章節(jié)，可以看到如下的描述：

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的實現(xiàn)。值得一提的是，這個類的責任其實是非常重大的，他兼容了spring的validation體系和hibernate的validation體系，也可以被開發(fā)者直接調(diào)用，代替上述的從工廠方法中獲取的hibernate validator。由于我們使用了springboot，會觸發(fā)web模塊的自動配置，LocalValidatorFactoryBean已經(jīng)成為了Validator的默認實現(xiàn)，使用時只需要自動注入即可。

@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接口的讀者會發(fā)現(xiàn)有兩個接口，一個是位于javax.validation包下，另一個位于org.springframework.validation包下，注意我們這里使用的是前者javax.validation，后者是spring自己內(nèi)置的校驗接口，LocalValidatorFactoryBean同時實現(xiàn)了這兩個接口。

<2> 此處校驗接口最終的實現(xiàn)類便是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> 校驗方法的返回值和入?yún)?/p>

<4> 添加一個異常處理器，可以獲得沒有通過校驗的屬性相關(guān)信息

基于方法的校驗，個人不推薦使用，感覺和項目結(jié)合的不是很好。

使用校驗框架的一些想法

理論上spring validation可以實現(xiàn)很多復雜的校驗，你甚至可以使你的Validator獲取ApplicationContext，獲取spring容器中所有的資源，進行諸如數(shù)據(jù)庫校驗，注入其他校驗工具，完成組合校驗（如前后密碼一致）等等操作，但是尋求一個易用性和封裝復雜性之間的平衡點是我們作為工具使用者應該考慮的，我推崇的方式，是僅僅使用自帶的注解和自定義注解，完成一些簡單的，可復用的校驗。而對于復雜的校驗，則包含在業(yè)務代碼之中，畢竟如用戶名是否存在這樣的校驗，僅僅依靠數(shù)據(jù)庫查詢還不夠，為了避免并發(fā)問題，還是得加上唯一索引之類的額外工作，不是嗎？

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論