吾皇一日不退役,尔等都是臣子java
【小家Java】深刻了解数据校验(Bean Validation):基础类打点(ValidationProvider、ConstraintDescriptor、ConstraintValidator)git
前几篇文章在讲Spring的数据绑定的时候,屡次提到过数据校验。可能有人认为数据校验模块并非那么的重要,由于硬编码均可以作。如果这么想的话,那就大错特错了~
前面讲解DataBinder
的时候一个小细节,它所在的包是:org.springframework.validation
,而且在分析源码的时候能看到DataBinder
它不只可以完成数据绑定,也提供了对数据校验的支持且还保存了校验结果。程序员
我以数据绑定DataBinder
为引子引出了数据校验这一块,是想代表它的重要性。连Java都把它抽象成了JSR标准
进行提出,so我认为这块是必修课,有必要了解本章的内容。github
数据校验 是很是常见的工做,在平常的开发中贯穿于代码的各个层次,从上层的View层到底层的数据层。web
在此处有必要再强调一句:前面说了数据绑定并不属于Spring MVC的专利,一样的数据校验也不是只会发生在web层,它能够在任意一层,从后面的示例中你会有更深的理解spring
在任什么时候候,当你要处理一个应用程序的业务逻辑,数据校验是你必须
要考虑和面对的事情。应用程序必须经过某种手段来确保输入进来的数据从语义上来说是正确的(好比生日必须是过去时,年龄必须>0等等~)。apache
咱们知道一般状况下程序确定是分层的,不一样的层通常由不一样的人来开发。若你是一个有经验的程序员, 我相信你确定见过在不一样的层了都出现了相同的校验代码,这就是某种意义上的垃圾代码。编程
public String queryValueByKey(String parmTemplateCode, String conditionName, String conditionKey, String resultName) { checkNotNull(parmTemplateCode, "parmTemplateCode not null"); checkNotNull(conditionName, "conditionName not null"); checkNotNull(conditionKey, "conditionKey not null"); checkNotNull(resultName, "resultName not null"); ... }
从这个简单的方法入参校验至少能发现以下问题:api
如上会致使代码冗余和一些管理的问题(代码量越大,管理起来维护起来就越困难),好比说语义的一致性等。为了不这样的状况发生,最好是将验证逻辑与相应的域模型(领域模型的概念)进行绑定,这就是本文提供的一个新思路(实际上是JavaEE提供的思路)缓存
为了解决这个问题,Bean Validation
为 JavaBean
验证定义了相应的元数据模型和 API。默认的元数据是 各类Java Annotations
,固然也支持xml方式而且你也能够扩展~
能够说Bean Validation
是JavaBean
的一个拓展,它能够布局于任意一层代码,不局限于Web应用仍是端应用。
JSR是Java Specification Requests
的缩写,意思是Java 规范提案。关于数据校验这块,最新的是JSR380
,也就是咱们常说的Bean Validation 2.0
。
Bean Validation 2.0 是JSR第380号标准。该标准链接以下:https://www.jcp.org/en/egc/view?id=380
Bean Validation的主页:http://beanvalidation.org
Bean Validation的参考实现:https://github.com/hibernate/hibernate-validator
Bean Validation
是一个经过配置注解来验证参数的框架,它包含两部分Bean Validation API
(规范)和Hibernate Validator
(实现)。
Bean Validation
是Java定义的一套基于注解/xml的数据校验规范,目前已经从JSR 303
的1.0版本升级到JSR 349
的1.1版本,再到JSR 380
的2.0版本(2.0完成于2017.08),已经经历了三个版本(我截图以下:)
如今绝大多数coder使用者其实都还在使用Bean Validation 1.1
,毕竟通常来讲它已经够用了~
本文会介绍Bean Validation 2.0
提供的一些实用的新东西,毕竟Java8如今已成为主流,彻底可使用了~
要想使用它,首先就得导包嘛~根据经验,和JCache相似Java只提供了规范,并无提供实现,因此咱们能够先找到它的API包而后导入:
<dependency> <groupId>javax.validation</groupId> <artifactId>validation-api</artifactId> <!-- <version>1.1.0.Final</version> --> <version>2.0.1.Final</version> </dependency>
关于版本之间的差别其实不是本文说明的重点,毕竟2.0作到了很好的向下兼容,使用起来是无缝的。
可是本处仍是给个1.1版本和2.0.1的截图,感官上简单对比一下区别:
Bean Validation | Hibernate Validation | JDK | Spring Boot |
---|---|---|---|
1.1 | 5.4 + | 6+ | 1.5.x |
2.0 | 6.0 + | 8+ | 2.0.x |
由于2.0推出的时间确实不算长,so此处我把一些重要的关注点列举以下:
List<@Email String>
@Past
和@Future
@Email,@NotEmpty,@NotBlank,@Positive, @PositiveOrZero,@Negative,@NegativeOrZero,@PastOrPresent和@FutureOrPresent
@Email、@NotEmpty、@NotBlank
以前是Hibernate额外提供的,2.0标准后hibernate自动退位让贤而且标注为过时了Bean Validation 2.0
的惟一实现为Hibernate Validator
。(其实还有Apache BVal
,可是你懂的,forget it)Hibernate Validator
,它本身也扩展了一些注解支持。@UniqueElements、@ISBN、@CodePointLength、、、、、、、、
@URL、@ScriptAssert、@SafeHtml、@Range、@ParameterScriptAssert、@Mod11Check、@Mod10Check、@LuhnCheck、@Length、@EAN、@Currency、@CreditCardNumber、@ConstraintComposition、@DurationMax、@DurationMin、**@REGON、@PESEL、@NIP、@TituloEleitoral、@CPF、@CNPJ**
Hibernate Validator
默认会校验完全部的属性,而后返回全部的验证失败信息
。开启fail fast mode后,只要有一个验证失败,则返回验证失败信息。so,对于Java Bean Validation
的实现落地产品就没啥好选的,导入Hibernate Validator
(最新版本)吧:
<dependency> <groupId>org.hibernate.validator</groupId> <artifactId>hibernate-validator</artifactId> <version>6.0.17.Final</version> </dependency>
==小细节:==
能够看到,导入了hibernate-validator
就必要再本身导入Java Bean Validation
API了,所以建议不用再手动导入API,交给内部来管理依赖。
定义一个待校验的普通JavaBean:
@Getter @Setter @ToString public class Person { // 错误消息message是能够自定义的 @NotNull(message = "名字不能为null") public String name; @Positive public Integer age; @NotNull @NotEmpty private List<@Email String> emails; @Future private Date start; }
书写测试用例:
public static void main(String[] args) { Person person = new Person(); //person.setName("fsx"); person.setAge(-1); // email校验:虽然是List均可以校验哦 person.setEmails(Arrays.asList("fsx@gmail.com", "baidu@baidu.com", "aaa.com")); //person.setStart(new Date()); //start 须要是一个未来的时间: Sun Jul 21 10:45:03 CST 2019 //person.setStart(new Date(System.currentTimeMillis() + 10000)); //校验经过 // 对person进行校验而后拿到结果(显然使用时默认的校验器) 会保留下校验失败的消息 Set<ConstraintViolation<Person>> result = Validation.buildDefaultValidatorFactory().getValidator().validate(person); // 对结果进行遍历输出 result.stream().map(v -> v.getPropertyPath() + " " + v.getMessage() + ": " + v.getInvalidValue()) .forEach(System.out::println); }
运行,报错啦:
Caused by: java.lang.ClassNotFoundException: javax.el.ELManager at java.net.URLClassLoader.findClass(URLClassLoader.java:382) ...
能够看到运行必须依赖于javax.el
这个包。(其实我是比较费解的,为什么校验框架非得依赖它呢?有小伙伴能够帮忙解释一下吗?)
那行,导入依赖javax.el
以及它的实现:
<!-- 注意这里导入的是Apr, 2013发布的el3.x的版本,可是glassfish并无对此版本进行支持了 固然tomcat确定是支持的 --> <dependency> <groupId>javax.el</groupId> <artifactId>javax.el-api</artifactId> <version>3.0.1-b06</version> </dependency> <!-- servlet容器大都对el有实现(支持jsp的都对此有实现),好比tomcat/glassfish等 --> <dependency> <groupId>org.glassfish.web</groupId> <artifactId>javax.el</artifactId> <version>2.2.6</version> </dependency>
须要注意的是,网上大都建议导入
org.glassfish.web
包。可是EL3.0后它并无再提供支持了,所以我我的是不建议使用它,而是使用下面tomcat的实现的~
关于EL的实现此处啰嗦一句:JavaEE并无提供el的实现,须要容器自行提供,好比上面你想要导入最为流行的tomcat
,你能够导入以下jar便可:
<!-- 嵌入式的tomcat --> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> <version>9.0.22</version> </dependency> <!-- 传统的tomcat(须要注意的是:传统的tomcat这种jar是不须要你手动导入的,tomcat自带的) --> <dependency> <groupId>org.apache.tomcat</groupId> <artifactId>tomcat-jasper-el</artifactId> <version>9.0.22</version> <scope>provided</scope> </dependency>
此处还须要说明一点的是:嵌入式tomcat(好比SpringBoot环境)若要使用时须要显示导入的。可是传统tomcat中你若要使用是不用本身导入的(tomcat自带此jar)。
可是,可是,可是自从tomcat8.5后再也不自带jsper-el的包了,须要手动导入。(tomcat7仍是有的~)
==最佳实践:==
通常来讲,javax.el-api
以及validation-api
都是没有必要单独导入的,第三方包都会自带。因此绝大数状况下,咱们只须要这么导入便可正常work,形以下面这样很是赶忙整洁:
<dependency> <groupId>org.hibernate.validator</groupId> <artifactId>hibernate-validator</artifactId> <version>6.0.17.Final</version> </dependency> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> <version>9.0.22</version> </dependency>
答:那是由于绝大多数状况下你使用@Valid是使用在Spring MVC上,它是不依赖于EL方式的,下篇文章会详细说明关于数据校验在Spring上的使用。而本文主要仍是讲解API的方式~
通过一番导包后,再次运行打印以下(方式1、方式二结果一致):
name名字不能为null: null // 此处错误消息是本身的自定义内容 age必须是正数: -1 emails[2].<list element>不是一个合法的电子邮件地址: aaa.com
这样经过API调用的方式就完成了对这个JavaBean
的属性校验~
官方给它的定义为:This class is the entry point for Bean Validation.
它做为校验的入口,有三种方式来启动它:
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
虽然是默认的单也会有以下2种状况:ValidationProviderResolver
实现类来处理ValidationProviderResolver
来跟XML配置逻辑选出一个ValidationProvider
来。大体代码以下:Configuration configuration = Validation.byDefaultProvider() .providerResolver(new MyResolverStrategy()) // 自定义一个ValidationProviderResolver的实现类 .configure(); ValidatorFactory factory = configuration.buildValidatorFactory();
ValidationProvider
实现。好比HibernateValidator
就是一个ValidationProvider
的实现:HibernateValidatorConfiguration configuration = Validation.byProvider(HibernateValidator.class) // .providerResolver( ... ) // 由于制定了Provider,这个参数就可选了 .configure() .failFast(false); ValidatorFactory validatorFactory = configuration.buildValidatorFactory();
这三种初始化方式,在源码处就是对应提供的三个public static
方法:
public class Validation { // 方式一 public static ValidatorFactory buildDefaultValidatorFactory() { return byDefaultProvider().configure().buildValidatorFactory(); } // 方式二 public static GenericBootstrap byDefaultProvider() { return new GenericBootstrapImpl(); } // 方式三 public static <T extends Configuration<T>, U extends ValidationProvider<T>> ProviderSpecificBootstrap<T> byProvider(Class<U> providerType) { return new ProviderSpecificBootstrapImpl<>( providerType ); } ... }
对于若你想使用xml文件独立配置校验规则,可使用Configuration.addMapping(new FileInputStream(validationFile));
,如今不多这么使用,略~
使用注意事项:ValidatorFactory
被建立后应该缓存起来再提供使用,由于它是县城安全的。
由于如今都会使用Hibernate-Validation
来处理校验,所以此处只关心方式三~
HibernateValidatorConfiguration
此接口表示配置,继承自标注接口javax.validation.Configuration
。很明显,它是HibernateValidator
的专属配置类
先看顶级接口:javax.validation.Configuration
,为构建ValidatorFactory
的配置类。默认状况下,它会读取配置文件META-INF/validation.xml
,Configuration提供的API方法是覆盖xml配置文件项的。若没有找到validation.xml
,就会使用默认的ValidationProviderResolver
也就是:DefaultValidationProviderResolver
。
public interface Configuration<T extends Configuration<T>> { // 该方法调用后就不会再去找META-INF/validation.xml了 T ignoreXmlConfiguration(); // 消息内插器 它是个狠角色,关于它的使用场景,后续会有详解(包括Spring都实现了它来作事) // 它的做用是:插入给定的约束冲突消息 T messageInterpolator(MessageInterpolator interpolator); // 肯定bean验证提供程序是否能够访问属性的协定。对每一个正在验证或级联的属性调用此约定。(Spring木有实现它) // 对每一个正在验证或级联的属性都会调用此约定 // Traversable: 可移动的 T traversableResolver(TraversableResolver resolver); // 建立ConstraintValidator的工厂 // ConstraintValidator:定义逻辑以验证给定对象类型T的给定约束A。(A是个注解类型) T constraintValidatorFactory(ConstraintValidatorFactory constraintValidatorFactory); // ParameterNameProvider:提供Constructor/Method的方法名们 T parameterNameProvider(ParameterNameProvider parameterNameProvider); // java.time.Clock 用做断定@Future和@Past(默认取值当前时间) // 若你但愿他是个逻辑实现,提供一个它便可 // @since 2.0 T clockProvider(ClockProvider clockProvider); // 值提取器。这是add哦~ 负责从Optional、List等这种容器里提取值~ // @since 2.0 T addValueExtractor(ValueExtractor<?> extractor); // 加载xml文件 T addMapping(InputStream stream); // 添加特定的属性给Provider用的。此属性等效于XML配置属性。 // 此方法一般是框架本身分析xml文件获得属性值而后放进去,调用者通常不使用(固然也能够用) T addProperty(String name, String value); // 下面都是get方法喽 MessageInterpolator getDefaultMessageInterpolator(); TraversableResolver getDefaultTraversableResolver(); ConstraintValidatorFactory getDefaultConstraintValidatorFactory(); ParameterNameProvider getDefaultParameterNameProvider(); ClockProvider getDefaultClockProvider(); BootstrapConfiguration getBootstrapConfiguration(); // 整个配置也可返回出去 // 上面都是工做,这个方法才是最终须要调用的:获得一个ValidatorFactory ValidatorFactory buildValidatorFactory(); }
该接口提供了一些标准的配置项。在实际应用中都是使用Hibernate Validation
,因此再看看这个具体的子接口:
public interface HibernateValidatorConfiguration extends Configuration<HibernateValidatorConfiguration> { // 这批属性,证实直接能够经过System属性值来控制,大大地方便~ // 这个机制快速失败机制:true检查完一个有错误就返回,false所有检查完把错误消息一块儿返回 默认false String FAIL_FAST = "hibernate.validator.fail_fast"; String ALLOW_PARAMETER_CONSTRAINT_OVERRIDE = "hibernate.validator.allow_parameter_constraint_override"; String ALLOW_MULTIPLE_CASCADED_VALIDATION_ON_RESULT = "hibernate.validator.allow_multiple_cascaded_validation_on_result"; String ALLOW_PARALLEL_METHODS_DEFINE_PARAMETER_CONSTRAINTS = "hibernate.validator.allow_parallel_method_parameter_constraint"; // @since 5.2 @Deprecated String CONSTRAINT_MAPPING_CONTRIBUTOR = "hibernate.validator.constraint_mapping_contributor"; // @since 5.3 String CONSTRAINT_MAPPING_CONTRIBUTORS = "hibernate.validator.constraint_mapping_contributors"; // @since 6.0.3 String ENABLE_TRAVERSABLE_RESOLVER_RESULT_CACHE = "hibernate.validator.enable_traversable_resolver_result_cache"; // @since 6.0.3 ScriptEvaluatorFactory:执行脚本 @Incubating String SCRIPT_EVALUATOR_FACTORY_CLASSNAME = "hibernate.validator.script_evaluator_factory"; // @since 6.0.5 comparing date/time in temporal constraints. In milliseconds. @Incubating String TEMPORAL_VALIDATION_TOLERANCE = "hibernate.validator.temporal_validation_tolerance"; // ResourceBundleMessageInterpolator用于 load resource bundles ResourceBundleLocator getDefaultResourceBundleLocator(); // 建立一个ConstraintMapping:经过编程API配置的约束映射 // 设置映射后,必须经过addMapping(constraintmapping)将其添加到此配置中。 ConstraintMapping createConstraintMapping(); // 拿到全部的值提取器 @since 6.0 @Incubating Set<ValueExtractor<?>> getDefaultValueExtractors(); // 往下就开始配置了~~~~~~~~~~ HibernateValidatorConfiguration addMapping(ConstraintMapping mapping); HibernateValidatorConfiguration failFast(boolean failFast); // used for loading user-provided resources: HibernateValidatorConfiguration externalClassLoader(ClassLoader externalClassLoader); // true:表示容许覆盖约束的方法。false表示不予许(抛出异常) 默认值是false HibernateValidatorConfiguration allowOverridingMethodAlterParameterConstraint(boolean allow); // 定义是否容许对返回值标记多个约束以进行级联验证。 默认是false HibernateValidatorConfiguration allowMultipleCascadedValidationOnReturnValues(boolean allow); // 定义约束的**并行方法**是否应引起ConstraintDefinitionException HibernateValidatorConfiguration allowParallelMethodsDefineParameterConstraints(boolean allow); // 是否容许缓存TraversableResolver 默认值是true HibernateValidatorConfiguration enableTraversableResolverResultCache(boolean enabled); // 设置一个脚本执行器 @Incubating HibernateValidatorConfiguration scriptEvaluatorFactory(ScriptEvaluatorFactory scriptEvaluatorFactory); // 容许在时间约束中比较日期/时间时设置可接受的偏差范围 // 好比@Past @PastOrPresent @Future @FutureOrPresent @Incubating HibernateValidatorConfiguration temporalValidationTolerance(Duration temporalValidationTolerance); // 容许设置将传递给约束验证器的有效负载。若是屡次调用该方法,则只传播最后传递的有效负载。 @Incubating HibernateValidatorConfiguration constraintValidatorPayload(Object constraintValidatorPayload); }
关于此接口的惟一实现类:ConfigurationImpl
,这里就不用再作分析了,由于对于Validation
这块,我们面向接口编程是彻底没有问题的~
准备好了Configuration
后,下一步显然就是configuration.buildValidatorFactory()
来获得一个ValidatorFactory
喽,关于ValidatorFactory
这块的内容,请听下文分解~
该文讲解是关于Bean Validation
数据校验,在如今Spring的高度封装下,愈来愈少的人可以主动去发现Java实现/标准了~
实际上Spring
的强大并非本身创造了多少轮子,而是它主要是带来了更为简单的抽象,从而减小样板代码、促进解耦、提升可单测性。所以对于有些经常使用的功能仍是建议稍微了解多一点,作到心中有数,运用起来也才会更加的游刃有余
若文章格式混乱,可点击
:原文连接-原文连接-原文连接-原文连接-原文连接
==The last:若是以为本文对你有帮助,不妨点个赞呗。固然分享到你的朋友圈让更多小伙伴看到也是被做者本人许可的~
==
若对技术内容感兴趣能够加入wx群交流:Java高工、架构师3群
。
若群二维码失效,请加wx号:fsx641385712
(或者扫描下方wx二维码)。而且备注:"java入群"
字样,会手动邀请入群