本文介绍了如何使用hibernate-validator解决后端参数验证问题，详细讲解了添加jar包、配置文件、默认注解校验、自定义注解校验以及分组校验的步骤，并通过实例展示了如何处理分页参数的校验，旨在提升代码的可读性和校验效率。
目录
2.1.2 方式二：下载hibernate-validator-5.2.2.Final.jar包放到项目里并引入
3.2.1 Bean Validation 中内置的 constraint
3.2.2 Hibernate Validator 附加的 constraint
第四章 hibernate-validator自定义注解校验
5.1 定义两个空接口，分别代表Person对象的增加校验规则和修改校验规则
第一章 当前要解决的问题
最近在项目中，后端人员遇到了一个共同的问题，就是测试提出的大量的后端参数验证的问题。最容易想到的解决方案是用简单的if判断参数是否满足条件，比如参数不能为null，email必须符合email的格式。 如果参数较少，这种方式还可以接受，但是如果需要校验的参数较多，手动进行if判断或者写正则表达式判断开发效率太慢，在时间、成本、质量的博弈中必然会落后。所以把校验层抽象出来是必然的。
Java程序开发中，当你要处理一个程序的业务逻辑时，请求参数的数据校验是必须要处理的。当请求参数格式不正确的时候，需要程序监测到，并且返回对应的错误提示，以此来达到数据校验的目的。对于前后端分离开发过程中，数据校验还需要返回对应的状态码和错误提示信息。在盐城信访项目中，我们理想的错误提示信息返回情况类似下图：
图1.1
笔者在被后台参数验证问题困扰了一段时间后，终于决定找出一个更加可行的方案，既不影响代码的可读性，更加方便快捷高效，那就是hibernate-validator。
第二章 hibernate-validator简介
hibernate-validator是Hibernate项目中的一个数据校验框架，是Bean Validation 的参考实现，hibernate-validator除了提供了JSR 349规范中所有内置constraint 的实现，还有一些附加的constraint 。使用hibernate-validator能够将数据校验从业务代码中脱离出来，增加代码可读性，同时也让数据校验变得更加方便、简单。
2.1 添加jar包
要使用hibernate-validator进行参数校验，首先要引入hibernate-validator的jar包。
2.1.1 方式一：添加Maven依赖支持
<!-- https://mvnrepository.com/artifact/org.hibernate/hibernate-validator -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.2.2.Final</version>
</dependency>
2.1.2 方式二：下载hibernate-validator-5.2.2.Final.jar包放到项目里并引入
本项目中使用的就是第二种方式。
图2.1
当然不管哪种方式，jar包的版本不仅限于5.2.2，可以根据实际情况选择jar包版本。
2.2 配置文件
在spring-mvc.xml文件中要有如下片段：
图2.2
第三章 hibernate-validator默认注解校验
在引入了hibernate-validator的jar包后，就可以使用hibernate-validator对后端参数进行校验了。
3.1在ExceptionHandlerAdvice中添加如下方法
图3.1
为了捕获默认注解校验失败抛出的异常，并按照RetJson格式返回错误信息，在ExceptionHandlerAdvice中添加
@ExceptionHandler(BindException.class)，
@ExceptionHandler(ConstraintViolationException.class)，
@ExceptionHandler({MissingServletRequestParameterException.class})代码。
//实体类上的异常捕获
@ExceptionHandler(BindException.class)
@ResponseStatus(HttpStatus.OK)
@ResponseBody
public RetJson illegalStateException(BindException e) {
return RetJson.error(validation(e.getBindingResult()));
}
private String validation(BindingResult bindingResult) {
List<ObjectError> errors = bindingResult.getAllErrors();
StringBuilder sb = new StringBuilder("");
if (!CollectionUtils.isEmpty(errors)) {
for (ObjectError error : errors) {
FieldError fieldError = (FieldError) error;
sb.append(fieldError.getDefaultMessage() + ",");
}
}
return sb.length()>0?sb.substring(0,sb.length()-1):"请求参数不合法";
}
//Controller层参数上的异常捕获
@ExceptionHandler(ConstraintViolationException.class)
@ResponseBody
@ResponseStatus(HttpStatus.BAD_REQUEST)
public RetJson handleValidationException(ConstraintViolationException e){
StringBuilder sb = new StringBuilder("");
for(ConstraintViolation<?> s:e.getConstraintViolations()){
sb.append(s.getMessage() + ",");
}
return RetJson.error(sb.length()>0?sb.substring(0,sb.length()-1):"请求参数不合法");
}
//required=true不满足时的异常捕获
//缺少参数异常
//getParameterName() 缺少的参数名称
@ExceptionHandler({MissingServletRequestParameterException.class})
@ResponseBody
public RetJson requestMissingServletRequest(MissingServletRequestParameterException ex){
//ex.printStackTrace();
return RetJson.error("缺少必要参数,参数名称为" + ex.getParameterName());
}3.2 默认的注解
hibernate Validator 是 Bean Validation 的参考实现 。Hibernate Validator 提供了 JSR 349 规范中所有内置 constraint 的实现，除此之外还有一些附加的 constraint。
在日常开发中，Hibernate Validator经常用来验证bean的字段，基于注解，方便快捷高效。
3.2.1 Bean Validation 中内置的 constraint
注解 作用
| @Valid | 被注释的元素是一个对象，需要检查此对象的所有字段值 |
| @Null | 被注释的元素必须为 null |
| @NotNull | 被注释的元素必须不为 null |
| @AssertTrue | 被注释的元素必须为 true |
| @AssertFalse | 被注释的元素必须为 false |
| @Min(value) | 被注释的元素必须是一个数字，其值必须大于等于指定的最小值 |
| @Max(value) | 被注释的元素必须是一个数字，其值必须小于等于指定的最大值 |
| @DecimalMin(value) | 被注释的元素必须是一个数字，其值必须大于等于指定的最小值 |
| @DecimalMax(value) | 被注释的元素必须是一个数字，其值必须小于等于指定的最大值 |
| @Size(max, min) | 被注释的元素的大小必须在指定的范围内 |
| @Digits (integer, fraction) | 被注释的元素必须是一个数字，其值必须在可接受的范围内 |
| @Past | 被注释的元素必须是一个过去的日期 |
| @Future | 被注释的元素必须是一个将来的日期 |
| @Pattern(value) | 被注释的元素必须符合指定的正则表达式 |
3.2.2 Hibernate Validator 附加的 constraint
| 注解 | 作用 |
| | 被注释的元素必须是电子邮箱地址 |
| @Length(min=, max=) | 被注释的字符串的大小必须在指定的范围内 |
| @NotEmpty | 被注释的字符串的必须非空 |
| @Range(min=, max=) | 被注释的元素必须在合适的范围内 |
| @NotBlank | 被注释的字符串的必须非空 |
| @URL(protocol=, | 被注释的字符串必须是一个有效的url |
| @CreditCardNumber | 被注释的字符串必须通过Luhn校验算法， |
| @ScriptAssert | 要有Java Scripting API 即JSR 223 |
| @SafeHtml | classpath中要有jsoup包 |
hibernate补充的注解中，最后3个不常用，可忽略。
主要区分下@NotNull @NotEmpty @NotBlank 3个注解的区别： @NotNull : 任何对象的value不能为null
@NotEmpty: 集合对象的元素不为0，即集合不为空，也可以用于字符串不为null
@NotBlank:只能用于字符串不为null，并且字符串trim()以后length要大于0
3.3 默认注解的使用方式
分为对Controller层的String参数的注解和对实体的注解。
废话不说，直接上代码。
3.3.1 对Controller中单个方法参数的注解
图3.2
自带的注解可能有默认的提示信息，但如果想要让返回自己想要的信息，可以在注解后面加上message = "str",这里的str代表任何想要返回的信息。如上图中的@NotBlank(message = "checkinIDNos不能为空")就是这种用法。这种方法要在Controller的类上加上注解@Validated，如图
图3.3
3.3.2 对实体的注解
图3.4
图3.5
在Controller的方法里，实体前面要标上@Validated，如上图中的@Validated PageEntity page。
第四章 hibernate-validator自定义注解校验
4.1 先新建一个注解
代码如下：
package com.bonc.ioc.common.validation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.validation.Constraint;
import javax.validation.Payload;
import com.bonc.ioc.common.validation.impl.MobilephoneNumValidator;
/**
* 验证手机号码
* @author 王芬芬
*
*/
@Target(value={ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = MobilephoneNumValidator.class)
public @interface MobilephoneNum {
/**
* @Description: 错误提示
*/
String message() default "请输入正确手机号码";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
4.2 创建验证类
package com.bonc.ioc.common.validation.impl;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;
import com.bonc.ioc.common.validation.MobilephoneNum;
/**
* 验证手机号码
* @author 王芬芬
*
*/
public class MobilephoneNumValidator implements ConstraintValidator<MobilephoneNum, String>{
@Override
public void initialize(MobilephoneNum arg0) {
// TODO Auto-generated method stub
}
@Override
public boolean isValid(String str, ConstraintValidatorContext arg1) {
if(str==null ||"".equals(str)){
return true;
}
Pattern p = null;
Matcher m = null;
boolean b = false;
p = Pattern.compile("^[1][3,4,5,7,8][0-9]{9}$"); // 验证手机号
m = p.matcher(str);
b = m.matches();
return b;
}
}
图4.1
上面的两段代码所在的文件在项目中的位置如图4.1所示，接下来就可以使用自定义注解@MobilephoneNum了，用法和默认注解的用法一样。
第五章 hibernate-validator分组校验
对同一个Model，我们在增加和修改时对参数的校验也是不一样的，这个时候我们就需要定义分组验证，步骤如下：
5.1 定义两个空接口，分别代表Person对象的增加校验规则和修改校验规则
图5.1
图5.2
5.2 Model上添加注解时使用指明所述的分组
图5.3
如果没写(groups = {Modify.class},message="身份证号码不能为空")标明分组，则默认相当于是Default.class组的。
也可以给一个属性同时配上多个组，
图5.4
图5.5
username可以同时被三组校验，password只配置了Add.class这一个组。
第六章 对分页参数的重新处理
因为前面提到的捕获异常的方法只能捕获Controller层的方法抛出的异常，对service层的方法抛出的异常无法捕获，而在盐城信访项目中分页参数的处理是放在了service层的。
图6.1
这个里面就算抛出了那三种捕获的异常类型，也不能被ExceptionHandlerAdvice类中的方法捕获。再加上这个方法在整个项目开发过程中应用极为广泛，所以对本方法的更改很有可能造成其他代码出现明显异常。我们尝试过在底层修改让其验证，如图
图6.2
但返回结果不太尽如人意。
看下面一个例子
@RequestMapping(value = "/selectVehicelRecordInfo")
@ResponseBody
public RetJson selectVehicelRecordInfo(
@NotBlank(message = "pageNumber参数不能为空")
@Pattern(regexp = "^[0-9]*[1-9][0-9]*$", message = "pageNumber应该是正 整数") @RequestParam(name = "pageNumber", required = true)
String pageNumber,
@NotBlank(message = "pageSize参数不能为空")
@Pattern(regexp = "^[0-9]*[1-9][0-9]*$", message = "pageSize应该是正整数")
@RequestParam(name = "pageSize", required = true)
String pageSize,
HttpServletRequest request) {
HashMap<String, Object> params = new HashMap<String, Object>();
String IDNo = request.getParameter("IDNo");
params.put("IDNo", IDNo);
try {
PageResult map = service.selectVehicelRecordInfo(params);
return RetJson.success(map);
} catch (Exception e) {
logger.error(e.getStackTrace());
return RetJson.error("程序异常,请求失败");
}
}如果用这种方式，直接在Contoller层去对分页参数单个注解校验，也能实现，但是分页有很多，分页参数的验证规则都一样，这样分开验证只会导致重复写。所以最后决定将对分页参数的校验专门建一个实体类PageEntity。
图6.3
实体类上暂时只对pageSize和pageNumber标上注解。但实际上还有一个潜在的验证就是orderBy和sort。这两个字段单独来讲是没什么要求的，可以空可以不空，但联合起来就有规则了，必须同时为空或者同时不为空，是配合使用的。所以还得一个专门的分页参数校验的方法。借鉴在做分页时的Service都继承项目中的BaseService，我们可以新建一个BasicController，把校验方法写到BasicController里面，让所有涉及到分页的Controller都继承BasicController。（为什么要建BasicController，之前已经说过，在service层抛出的异常无法被ExceptionHandlerAdvice类中的方法捕获，只有Controller中的可以被捕获。）
接下来看看这个BasicController是怎么写的。
图6.4
图6.5
getPageParams()方法就是处理分页参数的方法。后面的isBlank()方法是专门写的一个判断是否为空的方法，只要字段为null或字段的值去掉空格后是空字符串，都被认为该字段为空。
然后其他使用分页的Controller就可以继承这个BasicController。
图6.6
图6.7
如果用这种方式，获取userid的时候从原来的BaseService的getParamMap ()方法获取就有些没必要了，所以笔者在BaseService里添了一个专门获取userid的方法。
图6.8
鉴于分页在整个项目中用的地方很多，所以BaseService里的getParamMap()方法暂时保留。
以上就是笔者对hibernate-validator的全部介绍，有兴趣的读者可以查阅资料进行进一步研究。由于笔者能力有限，文档中存在的不足之处，敬请谅解。
扫一扫
2849
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
