Java开发中业务层入参校验详细解析

在这里插入图片描述
背景首先，我们达成以下共识：一个服务方法，如果入参太多，且基本为非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中呢？这样，调用方也能够清晰地看到基本的校验逻辑，其调用前也可以调用校验方法检查参数的合法性。具体实现

定义pojo要实现的校验接口
public interface ValidationHandler {public interface ValidationHandler {
/**
- 校验pojo的属性
- @return 通过/不通过
  */
  boolean isValid();
  }
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();
}
}
切面
此处切点使用注解：
@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(“参数校验不通过”);
}
}
}
}
}
调用结果自行写方法调用，能够正常执行到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

Java开发中业务层入参校验详细解析

猜你喜欢