关于spring:6-自定义容器类型元素验证类级别验证多字段联合验证

明天搬砖不狠，今天位置不稳。本文已被 https://www.yourbatman.cn 收录，外面一并有Spring技术栈、MyBatis、JVM、中间件等小而美的专栏供以收费学习。关注公众号【BAT的乌托邦】一一击破，深刻把握，回绝浅尝辄止。

✍前言

你好，我是YourBatman。

本文是上篇文章的续篇，集体倡议可先花3分钟移步上篇文章浏览一下：5. Bean Validation申明式验证四大级别：字段、属性、容器元素、类

很多人说Bean Validation只能验证单属性（单字段），但我却说它能实现99.99%的Bean验证，不信你可持续浏览本文，是否解你纳闷。

版本约定

• Bean Validation版本：2.0.2
• Hibernate Validator版本：6.1.5.Final

✍注释

本文接上文叙述，持续介绍Bean Validation申明式验证四大级别中的：容器元素验证（自定义容器类型）以及类级别验证（也叫多字段联结验证）。

据我理解，很多小伙伴对这部分内容并不相熟，遇到相似场景往往被迫只能是一半BV验证 + 一半事务脚本验证的形式，显得洋不洋俗不俗。 本文将给出具体案例场景，而后对立应用BV来解决数据验证问题，心愿能够帮忙到你，给予参考之作用。

自定义容器类型元素验证

通过上文咱们曾经晓得了Bean Validation是能够对形如List、Set、Map这样的容器类型外面的元素进行验证的，内置反对的容器尽管能cover大部分的应用场景，但未免有的场景仍旧不能笼罩，而且这个可能还十分罕用。

譬如咱们都不生疏的办法返回值容器Result<T>，构造形如这样（最简模式，仅供参考）：

@Datapublic final class Result<T> implements Serializable {    private boolean success = true;    private T data = null;        private String errCode;    private String errMsg;}

Controller层用它包装（装载）数据data，形如这样：

@GetMapping("/room")Result<Room> room() { ... }public class Room {    @NotNull    public String name;    @AssertTrue    public boolean finished;}

这个时候心愿对Result<Room>外面的Room进行合法性验证：借助BV进行申明式验证而非硬编码。心愿这么写就能够了：Result<@Notnull @Valid LoggedAccountResp>。显然，缺省状况下即便这样申明了束缚注解也是有效的，毕竟Bean Validation基本就“不意识”Result这个“容器”，更别提验证其元素了。

好在Bean Validation对此提供了扩大点。上面我将一步一步的来对此提供实现，让验证优雅再次起来。

• 自定义一个能够从Result<T>里提取出T值的ValueExtractor值提取器

Bean Validation容许咱们对自定义容器元素类型进行反对。通过后面这篇文章：4. Validator校验器的五大外围组件，一个都不能少 晓得要想反对自定义的容器类型，须要注册一个自定义的ValueExtractor用于值的提取。

/** * 在此处增加备注信息 * * @author yourbatman * @site https://www.yourbatman.cn * @date 2020/10/25 10:01 * @see Result */public class ResultValueExtractor implements ValueExtractor<Result<@ExtractedValue ?>> {        @Override    public void extractValues(Result<?> originalValue, ValueReceiver receiver) {        receiver.value(null, originalValue.getData());    }}

• 将此自定义的值提取器注册进验证器Validator里，并提供测试代码：

把Result作为一个Filed字段装进Java Bean里：

public class ResultDemo {    public Result<@Valid Room> roomResult;}

测试代码：

public static void main(String[] args) {    Room room = new Room();    room.name = "YourBatman";    Result<Room> result = new Result<>();    result.setData(room);    // 把Result作为属性放进去    ResultDemo resultDemo = new ResultDemo();    resultDemo.roomResult = result;    // 注册自定义的值提取器    Validator validator = ValidatorUtil.obtainValidatorFactory()            .usingContext()            .addValueExtractor(new ResultValueExtractor())            .getValidator();    ValidatorUtil.printViolations(validator.validate(resultDemo));}

运行测试程序，输入：

roomResult.finished只能为true，但你的值是： false

完满的实现了对Result“容器”里的元素进行了验证。

小贴士：本例是把Result作为Java Bean的属性进行试验的。实际上大多数状况下是把它作为办法返回值进行校验。形式相似，有趣味的同学可自行触类旁通哈

在此弱弱补一句，若在Spring Boot场景下你想像这样对Result<T>提供反对，那么你须要自行提供一个验证器来笼罩掉主动拆卸进去的，可参考ValidationAutoConfiguration。

类级别验证（多字段联结验证）

束缚也能够放在类级别上（也就说注解标注在类上）。在这种状况下，验证的主体不是单个属性，而是整个对象。如果验证依赖于对象的几个属性之间的相关性，那么类级别束缚就能搞定这所有。

这个需要场景在平时开发中也十分常见，比方此处我举个场景案例：Room示意一个教室，maxStuNum示意该教室容许的最大学生数，studentNames示意教室外面的学生们。很显著这里存在这么样一个规定：学生总数不能大于教室容许的最大值，即studentNames.size() <= maxStuNum。如果用事务脚本来实现这个验证规定，那么你的代码里必定穿插着相似这样的代码：

if (room.getStudentNames().size() > room.getMaxStuNum()) {    throw new RuntimeException("...");}

尽管这么做也能达到校验的成果，但很显著这不够优雅。冀望这种case仍旧能借助Bean Validation来优雅实现，上面我来走一把。

相较于后面但字段/属性验证的应用case，这个须要验证的是整个对象（多个字段）。上面呀，我给出两种实现形式，供以参考。

形式一：基于内置的@ScriptAssert实现

虽说Bean Validation没有内置任何类级别的注解，但Hibernate-Validator却对此提供了加强，补救了其有余。@ScriptAssert就是HV内置的一个十分弱小的、能够用于类级别验证注解，它能够很容易的解决这种case：

@ScriptAssert(lang = "javascript", alias = "_", script = "_.maxStuNum >= _.studentNames.length")@Datapublic class Room {    @Positive    private int maxStuNum;    @NotNull    private List<String> studentNames;}

@ScriptAssert反对写脚本来实现验证逻辑，这里应用的是javascript（缺省状况下的惟一抉择，也是默认抉择）

测试用例：

public static void main(String[] args) {    Room room = new Room();    ValidatorUtil.printViolations(ValidatorUtil.obtainValidator().validate(room));}

运行程序，抛错：

Caused by: <eval>:1 TypeError: Cannot get property "length" of null    at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)    at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213)    ...

这个报错意思是_.studentNames值为null，也就是room.studentNames字段的值为null。

what？它头上不明明标了@NotNull注解吗，怎么可能为null呢？这其实波及到后面所讲到的一个小知识点，这里提一嘴：所有的束缚注解都会执行，不存在短路成果（除非校验程序抛异样），只有你敢标，我就敢执行，所以这里为嘛报错你懂了吧。

小贴士：@ScriptAssert对null值并不免疫，不论咋样它都会执行的，因而书写脚本时留神判空哦

当然喽，多个束缚之间的执行也是能够排序（有序的），这就波及到多个束缚的执行程序（序列）问题，本文暂且绕过。例子种先给填上一个值，后续再专文详解多个束缚注解执行序列问题和案例分析。

批改测试脚本（减少一个学生，让其不为null）：

public static void main(String[] args) {    Room room = new Room();    room.setStudentNames(Collections.singletonList("YourBatman"));    ValidatorUtil.printViolations(ValidatorUtil.obtainValidator().validate(room));}

再次运行，输入：

执行脚本表达式"_.maxStuNum >= _.studentNames.length"没有返回冀望后果，但你的值是： Room(maxStuNum=0, studentNames=[YourBatman])maxStuNum必须是负数，但你的值是： 0

验证后果合乎预期：0（maxStuNum） < 1（studentNames.length）。

小贴士：若测试脚本中减少一句room.setMaxStuNum(1);，那么请问后果又如何呢？

形式二：自定义注解形式实现

虽说BV自定义注解前文还暂没提到，但这并不难，因而这里先混个脸熟，也可在浏览到前面文章后再杀个回马枪回来。

• 自定义一个束缚注解，并且提供束缚逻辑的实现

@Target({TYPE, ANNOTATION_TYPE})@Retention(RUNTIME)@Constraint(validatedBy = {ValidStudentCountConstraintValidator.class})public @interface ValidStudentCount {    String message() default "学生人数超过最大限额";    Class<?>[] groups() default {};    Class<? extends Payload>[] payload() default {};}

public class ValidStudentCountConstraintValidator implements ConstraintValidator<ValidStudentCount, Room> {    @Override    public void initialize(ValidStudentCount constraintAnnotation) {    }    @Override    public boolean isValid(Room room, ConstraintValidatorContext context) {        if (room == null) {            return true;        }        boolean isValid = false;        if (room.getStudentNames().size() <= room.getMaxStuNum()) {            isValid = true;        }        // 自定义提醒语（当然你也能够不自定义，那就应用注解里的message字段的值）        if (!isValid) {            context.disableDefaultConstraintViolation();            context.buildConstraintViolationWithTemplate("校验失败xxx")                    .addPropertyNode("studentNames")                    .addConstraintViolation();        }        return isValid;    }}

• 书写测试脚本

public static void main(String[] args) {    Room room = new Room();    room.setStudentNames(Collections.singletonList("YourBatman"));    ValidatorUtil.printViolations(ValidatorUtil.obtainValidator().validate(room));}

运行程序，输入：

maxStuNum必须是负数，但你的值是： 0studentNames校验失败xxx，但你的值是： Room(maxStuNum=0, studentNames=[YourBatman])

完满，完全符合预期。

这两种形式都能够实现类级别的验证，它俩能够说各有优劣，次要体现在如下方面：

• @ScriptAssert是内置就提供的，因而应用起来十分的不便和通用。但毛病也是因为过于通用，因而语义上不够显著，须要浏览脚本才知。举荐大量（非重复使用）、逻辑较为简单时应用
• 自定义注解形式。毛病当然是“开箱应用”起来稍显麻烦，但它的长处就是语义明确，灵便且不易出错，即便是简单的验证逻辑也能轻松搞定

总之，若你的验证逻辑只用一次（只一个中央应用）且简略（比方只是简略判断而已），举荐应用@ScriptAssert更为笨重。否则，你懂的~

✍总结

如果说能纯熟应用Bean Validation进行字段、属性、容器元素级别的验证是及格60分的话，那么可能应用BV解决本文中几个场景问题的话就应该达到优良级80分了。

本文举例的两个场景：Result<T>和多字段联结验证均属于平时开发中比拟常见的场景，如果能让Bean Validation染指帮解决此类问题，置信对提效是很有帮忙的，说不定你还能成为团队中最靓的仔呢。

✔举荐浏览：

• 1. 不吹不擂，第一篇就能晋升你对Bean Validation数据校验的认知
• 2. Bean Validation申明式校验办法的参数、返回值
• 3. 站在应用层面，Bean Validation这些标准接口你须要烂熟于胸
• 4. Validator校验器的五大外围组件，一个都不能少
• 5. Bean Validation申明式验证四大级别：字段、属性、容器元素、类

♥关注YourBatman♥