背景首先，我們達成以下共識：一個服務方法，如果入參太多，且基本為非pojo，會給呼叫方造成不必要的干擾。儘管可以把文件寫的很完善，但還是建議使用pojo對多個引數合理封裝。
如下示例：
@Data
public class UserVo {
private String username;
private Integer age;
private List 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 {public interface ValidationHandler {
   /**

   • 校驗pojo的屬性
   • @return 通過/不通過
     */
     boolean isValid();
     }

2. pojo實現介面ValidationHandler，編寫校驗邏輯
   @Data
   public class UserVo implements ValidationHandler {

   private String username;
   private Integer age;
   private List 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 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) {

    // 業務邏輯操作
   

   }
   }
   是不是很熟悉呢？校驗效果和前面一樣，種一棵樹最好的時間是十年前，而後是現在！
   文章來自：https://www.itjmd.com/news/show-4310.html