業務層方法入參校驗的思考與實踐
背景
首先,我們達成以下共識:
- 一個服務方法,如果入參太多,且基本為非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) {
// 業務邏輯操作
}
}
是不是很熟悉呢?校驗效果和前面一樣。