Java開發中業務層入參校驗詳細解析

背景

首先，咱們達成如下共識：

• 一個服務方法，若是入參太多，且基本爲非pojo，會給調用方形成沒必要要的干擾。儘管能夠把文檔寫的很完善，但仍是建議使用pojo對多個參數合理封裝。
  以下示例：

@Data
public class UserVo {
    private String       username;
    private Integer      age;
    private List<String> hobby;
}

• 執行方法都應該對入參進行校驗。對於一些通用的簡單的不涉及業務邏輯的校驗，好比字符串不爲空，數字的範圍限制，咱們不必將校驗代碼寫在方法內部。以下示例

@Service
public class UserService {

    public void addUser(UserVo userVo) {
        // 參數基本校驗
        if (StringUtils.isEmpty(userVo.getUsername())
                || userVo.getAge() < 0
                || userVo.getAge() > 200
                || CollectionUtils.isEmpty(userVo.getHobby())) {
            throw new IllegalArgumentException();
        }
        
        // 業務邏輯操做
    }
}

• 咱們的項目採用了spring框架，這是標配，且service bean是要被調用的。

實現思路

有了上述共識以後，咱們來開始實現一點想法：結合Spring的切面用法，可以很方便的拿到切點的方法入參，而後能夠進行參數校驗。

比較常見的一種方式是：使用Java bean註解校驗。大體用法就是：在pojo加上相應的校驗註解，而後在切面中利用hibernate-validator進行校驗。這種方式springmvc已經幫咱們實現了，並且使用效果不錯。

@Data
public class UserVo {

    @NotEmpty
    private String       username;
    
    @Max(value = 200)
    @Min(value = 1)
    private Integer      age;
    
    @NotEmpty
    private List<String> hobby;
}

前面提到，暴露的方法儘可能簡潔易用，不要形成太多的干擾。pojo的屬性應該保持簡潔，加上必要的註釋。

咱們本來的想法就是，利用切面把方法中大量相似的簡單的校驗邏輯抽離出來，在切面中執行校驗的過程。不一樣pojo有不一樣的屬性，那麼校驗邏輯仍是會存在不一樣，若是不使用註解校驗，在切面中拿到了不一樣的pojo，可能會寫不少的 instance of判斷，固然也能夠利用設計模式實現的很好。總之，咱們確實把service方法中的校驗抽離出來了。

鋪墊了這麼多，咱們爲何不能夠把校驗邏輯放進對應的pojo中呢？這樣，調用方也可以清晰地看到基本的校驗邏輯，其調用前也能夠調用校驗方法檢查參數的合法性。

具體實現

1. 定義pojo要實現的校驗接口

public interface ValidationHandler {
    /**
     * 校驗pojo的屬性
     *
     * @return 經過/不經過
     */
    boolean isValid();
}

2. pojo實現接口ValidationHandler，編寫校驗邏輯

@Data
public class UserVo implements ValidationHandler {

    private String       username;
    private Integer      age;
    private List<String> hobby;

    @Override
    public boolean isValid() {
        return StringUtils.isNotEmpty(username)
                && age > 0
                && age < 100
                && !hobby.isEmpty();
    }
}

3. 切面

• 此處切點使用註解：

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ParamValidation {
}

• 在service中使用

@Service
public class UserService {

    @ParamValidation
    public void addUser(UserVo userVo) {
    
        // 業務邏輯操做
    }
}

• 具體切面代碼

@Component @Aspect
public class ParamValidator {

    @Pointcut("@annotation(com.ex.validator.ParamValidation)")
    public void validate() { }

    @Before("validate()")
    public void before(JoinPoint joinPoint) {
        for (Object arg : joinPoint.getArgs()) {
            if (arg instanceof ValidationHandler) {
                if (!((ValidationHandler) arg).isValid()) {
                    throw new IllegalArgumentException("參數校驗不經過");
                }
            }
        }
    }
}

4. 調用結果

自行寫方法調用，可以正常執行到aop校驗

升級版

原本寫到這裏就結束了，偶然發現了一個彩蛋，因而有了升級版。

咱們看一下bean validation的標準註解@javax.validation.constraints.AssertTrue，這個註解要求bean的屬性爲true，除了放在屬性上，也能夠放在get/is方法上。通過測試，==能夠放在自定義方法上，該方法名需以is或get開頭==。

說到底，咱們就幹了一件事：把校驗邏輯放進對應的pojo。其實上面的實現都是不必的，既然都用上了，就不重複造輪子了。把自定義接口和切面都去掉，UserVo能夠變成以下：

@Data
public class UserVo {

    private String       username;
    private Integer      age;
    private List<String> hobby;

    @AssertTrue
    public boolean isValid() {
        return StringUtils.isNotEmpty(username)
                && age > 0
                && age < 100
                && !hobby.isEmpty();
    }
}

service方法就變成了：

@Validated //打開校驗開關
@Service
public class UserService {

    // 入參pojo添加@Valid
    public void addUser(@Valid UserVo userVo) {

        // 業務邏輯操做
    }
}

是否是很熟悉呢？校驗效果和前面同樣，種一棵樹最好的時間是十年前，然後是如今！