在日常的接口开发中，为了保证接口的稳定安全，我们一般需要在接口逻辑中处理两种校验：
- 参数校验
- 业务规则校验
参数校验
后端要对前端传来得参数做各种校验，如果使用if-else语句会使代码可读性降低，不简洁，此时可以使用一些第三方校验工具类
引入依赖
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-validator</artifactId> <version>4.3.1.Final</version> </dependency>
常用注解
| 注解 | 说明 |
| @Length(min=,max=) | 检查所属的字段的长度是否在min和max之间，只能用于字符串 |
| @Range(min=,max=,message=) | 被注释的元素必须在合适的范围内 |
| @Max | 该字段的值只能小于或等于该值 |
| @Min | 该字段的值只能大于或等于该值 |
| @NotNull | 不能为null |
| @NotBlank | 不能为空，检查时会将空格忽略 |
| @NotEmpty | 不能为空，这里的空是指空字符串 |
| @Pattern(regex=,flag=) | 被注释的元素必须符合指定的正则表达式 |
需要在controller中搭配@Validated或@Valid注解一起使用，@Validated或@Valid注解一起使用区别不是很大 ，二选一
| 注解 | @Validated | @Valid |
| 所属的包 | 属于org.springframework.validation.annotation包下的,是spring提供的 | 属于javax.validation包下,是jdk给提供的 |
| 是否支持分组和排序 | 是 | 否 |
虽然@Validated比@Valid更加强大，在@Valid之上提供了分组功能和验证排序功能，不过在实际项目中一直没有用到过 Hibernate-validate框架中的注解是需要加在实体中一起使用的
案例实体
public class DataSetSaveVO { //唯一标识符为空 @NotBlank(message = "user uuid is empty") //用户名称只能是字母和数字 @Pattern(regexp = "^[a-z0-9]+$", message = "user names can only be alphabetic and numeric") @Length(max = 48, message = "user uuid length over 48 byte") private String userUuid; //数据集名称只能是字母和数字 @Pattern(regexp = "^[A-Za-z0-9]+$", message = "data set names can only be letters and Numbers") //文件名称过长 @Length(max = 48, message = "file name too long") //文件名称为空 @NotBlank(message = "file name is empty") private String name; //数据集描述最多为256字节 @Length(max = 256, message = "data set description length over 256 byte") //数据集描述为空 @NotBlank(message = "data set description is null") private String description; }
说明：message字段为不符合校验规则时抛出的异常信息
controller
@PostMapping public ResponseVO createDataSet(@Valid @RequestBody DataSetSaveVO dataSetVO) { return ResponseUtil.success(dataSetService.saveDataSet(dataSetVO)); }
commons-lang3
<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.4</version> </dependency>
方法
| 方法 | 说明 |
| CollectionUtils.isEmpty | 判断集合是否为空，为null或者size==0，返回true |
| CollectionUtils.isNotEmpty | 判断集合是否为非空 |
| StringUtils.isEmpty | 判断字符串是否为空 |
| StringUtils.isNotEmpty | 判断字符串是否非空 |
| StringUtils.isBlank | 判断字符串是否为空，为null或者size==0或者只存在空白字符(如" ")，则返回true |
| StringUtils.isNotBlank | 判断字符串是否为非空 |
测试代码
//StringUtils.isEmpty System.out.println(StringUtils.isEmpty("")); //true System.out.println(StringUtils.isEmpty(" ")); //false //StringUtils.isNotEmpty System.out.println(StringUtils.isNotEmpty("")); //false //StringUtils.isBlank System.out.println(StringUtils.isBlank("")); //true System.out.println(StringUtils.isBlank(" ")); //true //StringUtils.isNotBlank System.out.println(StringUtils.isNotBlank(" ")); //false List<Integer> emptyList = new ArrayList<>(); List<Integer> nullList = null; List<Integer> notEmptyList = new ArrayList<>(); notEmptyList.add(1); //CollectionUtils.isEmpty System.out.println(CollectionUtils.isEmpty(emptyList)); //true System.out.println(CollectionUtils.isEmpty(nullList)); //true System.out.println(CollectionUtils.isEmpty(notEmptyList)); //false //CollectionUtils.isNotEmpty System.out.println(CollectionUtils.isNotEmpty(emptyList)); //false System.out.println(CollectionUtils.isNotEmpty(nullList)); //false System.out.println(CollectionUtils.isNotEmpty(notEmptyList)); //true
自定义注解
当上面的方面都无法满足校验的需求以后，可以考虑使用自定义注解。
业务规则校验
业务规则校验指接口需要满足某些特定的业务规则，举个例子：业务系统的用户需要保证其唯一性，用户属性不能与其他用户产生冲突，不允许与数据库中任何已有用户的用户名称、手机号码、邮箱产生重复。
这就要求在创建用户时需要校验用户名称、手机号码、邮箱是否被注册 ；编辑用户时不能将信息修改成已有用户的属性 。
95%的程序员当面对这种业务规则校验时往往选择写在service逻辑中，常见的代码逻辑如下：
public void create(User user) { Account account = accountDao.queryByUserNameOrPhoneOrEmail(user.getName(),user.getPhone(),user.getEmail()); if (account != null) { throw new IllegalArgumentException("用户已存在，请重新输入"); } }
最优雅的实现方法应该是参考 Bean Validation 的标准方式，借助自定义校验注解完成业务规则校验。
接下来我们通过上面提到的用户接口案例，通过自定义注解完成业务规则校验。
首先我们需要创建两个自定义注解，用于业务规则校验：
UniqueUser:表示一个用户是唯一的，唯一性包含：用户名，手机号码、邮箱
@Documented @Retention(RUNTIME) @Target({FIELD, METHOD, PARAMETER, TYPE}) @Constraint(validatedBy = UserValidation.UniqueUserValidator.class) public @interface UniqueUser { String message() default "用户名、手机号码、邮箱不允许与现存用户重复"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; }
NotConflictUser:表示一个用户的信息是无冲突的，无冲突是指该用户的敏感信息与其他用户不重合
@Documented @Retention(RUNTIME) @Target({FIELD, METHOD, PARAMETER, TYPE}) @Constraint(validatedBy = UserValidation.NotConflictUserValidator.class) public @interface NotConflictUser { String message() default "用户名称、邮箱、手机号码与现存用户产生重复"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; }
- 想让自定义验证注解生效，需要实现
ConstraintValidator接口。接口的第一个参数是 自定义注解类型 ，第二个参数是 被注解字段的类 ，因为需要校验多个参数，我们直接传入用户对象。需要提到的一点是ConstraintValidator接口的实现类无需添加@Component它在启动的时候就已经被加载到容器中了。
@Slf4j public class UserValidation<T extends Annotation> implements ConstraintValidator<T, User> { protected Predicate<User> predicate = c -> true; @Resource protected UserRepository userRepository; @Override public boolean isValid(User user, ConstraintValidatorContext constraintValidatorContext) { return userRepository == null || predicate.test(user); } /** * 校验用户是否唯一 * 即判断数据库是否存在当前新用户的信息，如用户名，手机，邮箱 */ public static class UniqueUserValidator extends UserValidation<UniqueUser>{ @Override public void initialize(UniqueUser uniqueUser) { predicate = c -> !userRepository.existsByUserNameOrEmailOrTelphone(c.getUserName(),c.getEmail(),c.getTelphone()); } } /** * 校验是否与其他用户冲突 * 将用户名、邮件、电话改成与现有完全不重复的，或者只与自己重复的，就不算冲突 */ public static class NotConflictUserValidator extends UserValidation<NotConflictUser>{ @Override public void initialize(NotConflictUser notConflictUser) { predicate = c -> { log.info("user detail is {}",c); Collection<User> collection = userRepository.findByUserNameOrEmailOrTelphone(c.getUserName(), c.getEmail(), c.getTelphone()); // 将用户名、邮件、电话改成与现有完全不重复的，或者只与自己重复的，就不算冲突 return collection.isEmpty() || (collection.size() == 1 && collection.iterator().next().getId().equals(c.getId())); }; } } }
- 这里使用Predicate函数式接口对业务规则进行判断。
使用
@RestController @RequestMapping("/senior/user") @Slf4j @Validated public class UserController { @Autowired private UserRepository userRepository; @PostMapping public User createUser(@UniqueUser @Valid User user){ User savedUser = userRepository.save(user); log.info("save user id is {}",savedUser.getId()); return savedUser; } @SneakyThrows @PutMapping public User updateUser(@NotConflictUser @Valid @RequestBody User user){ User editUser = userRepository.save(user); log.info("update user is {}",editUser); return editUser; } }
- 使用很简单，只需要在方法上加入自定义注解即可，业务逻辑中不需要添加任何业务规则的代码
通过上面几步操作，业务校验便和业务逻辑就完全分离开来，在需要校验时用@Validated注解自动触发，或者通过代码手动触发执行，可根据你们项目的要求，将这些注解应用于控制器、服务层、持久层等任何层次的代码之中。
这种方式比任何业务规则校验的方法都优雅，推荐大家在项目中使用。在开发时可以将不带业务含义的格式校验注解放到 Bean 的类定义之上，将带业务逻辑的校验放到 Bean 的类定义的外面。这两者的区别是放在类定义中的注解能够自动运行，而放到类外面则需要像前面代码那样，明确标出注解时才会运行。
