0
点赞
收藏
分享

微信扫一扫

Springboot中如何优雅的进行字段以及业务校验


在日常的接口开发中,为了保证接口的稳定安全,我们一般需要在接口逻辑中处理两种校验:

  1. 参数校验
  2. 业务规则校验

参数校验

后端要对前端传来得参数做各种校验,如果使用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 的类定义的外面。这两者的区别是放在类定义中的注解能够自动运行,而放到类外面则需要像前面代码那样,明确标出注解时才会运行。

举报

相关推荐

0 条评论