背景
首先,我们达成以下共识:
一个服务方法,如果入参太多,且基本为非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 {
/**
* 校验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) {
// 业务逻辑操作
}
}
是不是很熟悉呢?校验效果和前面一样,种一棵树最好的时间是十年前,而后是现在!