Spring validation 後端校驗【轉】

時間 2019-11-17

原文原文鏈接

本文來自下一秒昇華的CSDN 博客，全文地址請點擊：https://blog.csdn.net/u013815546/article/details/77248003?utm_source=copy

前言

數據的校驗是交互式網站一個不可或缺的功能，前端的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中自動校驗的機制。java

引入依賴

咱們使用maven構建springboot應用來進行demo演示。git

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

咱們只須要引入spring-boot-starter-web依賴便可，若是查看其子依賴，能夠發現以下的依賴：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模塊也提供了相應的數據綁定功能。正則表達式

構建啓動類

無需添加其餘註解，一個典型的啓動類spring

@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以下所示。bootstrap

@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-30三、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容器中全部的資源，進行諸如數據庫校驗，注入其餘校驗工具，完成組合校驗（如先後密碼一致）等等操做，可是尋求一個易用性和封裝複雜性之間的平衡點是咱們做爲工具使用者應該考慮的，我推崇的方式，是僅僅使用自帶的註解和自定義註解，完成一些簡單的，可複用的校驗。而對於複雜的校驗，則包含在業務代碼之中，畢竟如用戶名是否存在這樣的校驗，僅僅依靠數據庫查詢還不夠，爲了不併發問題，仍是得加上惟一索引之類的額外工做，不是嗎？