关于github:改进-hibernatevalidator新一代校验框架-validator-使用介绍-v04

我的项目介绍

java 开发中，参数校验是十分常见的需要。然而 hibernate-validator 在应用过程中，仍然会存在一些问题。

validator 在 hibernate-validator 等校验工具之上，做了一些改良，使其应用更加便捷优雅，进一步晋升工作效率。

变更日志

变更日志

个性

• 反对 fluent-validation
• 反对 jsr-303 注解
• 反对 i18n
• 反对用户自定义策略
• 反对用户自定义注解
• 反对针对属性的校验
• 反对过程式编程与注解式编程
• 反对指定校验失效的条件

创作目标

hibernate-validator 无奈满足的场景

现在 java 最风行的 hibernate-validator 框架，然而有些场景是无奈满足的。

比方：

1. 验证新密码和确认明码是否雷同。(同一对象下的不同属性之间关系)
2. 当一个属性值满足某个条件时，才进行其余值的参数校验。
3. 多个属性值，至多有一个不能为 null

其实，在对于多个字段的关联关系解决时，hibernate-validator 就会比拟弱。

本我的项目联合原有的长处，进行这一点的性能强化。

validation-api 过于简单

validation-api 提供了丰盛的个性定义，也同时带来了一个问题。

实现起来，特地简单。

然而咱们理论应用中，经常不须要这么简单的实现。

validator-api 提供了一套简化很多的 api，便于用户自行实现。

自定义不足灵活性

hibernate-validator 在应用中，自定义束缚实现是基于注解的，针对单个属性校验不够灵便。

本我的项目中，将属性校验束缚和注解束缚辨别开，便于复用和拓展。

过程式编程 vs 注解式编程

hibernate-validator 外围反对的是注解式编程，基于 bean 的校验。

一个问题是针对属性校验不灵便，有时候针对 bean 的校验，还是要本人写判断。

本我的项目反对 fluent-api 进行过程式编程，同时反对注解式编程。

尽可能兼顾灵活性与便利性。

疾速开始

筹备工作

JDK1.7+

Maven 3.X+

maven 引入

<dependency>    <groupId>com.github.houbb</groupId>    <artifactId>validator-core</artifactId>    <version>0.4.0</version></dependency>

疾速入门

定义对象

第一步，咱们定义一个常见的 java bean 对象，能够指定内置的注解。

反对 jsr-303 注解和 hibernate-validator 的注解。

public class User {    /**     * 名称     */    @HasNotNull({"nickName"})    private String name;    /**     * 昵称     */    private String nickName;    /**     * 原始明码     */    @AllEquals("password2")    private String password;    /**     * 新密码     */    private String password2;    /**     * 性别     */    @Ranges({"boy", "girl"})    private String sex;    /**     * 失败类型枚举     */    @EnumRanges(FailTypeEnum.class)    private String failType;        //getter & setter}

ValidHelper 工具办法

ValidHelper 作为对立封装的工具类，提供了 java bean 校验常见的办法。

办法列表：

应用起来很简略，咱们以 failFast 为例：

// 对象定义User user = new User();user.sex("what").password("old").password2("new");// 调用办法IResult result = ValidHelper.failFast(user);

后果：

DefaultResult{pass=false, notPassList=[DefaultConstraintResult{pass=false, message='name: 值 <null> 不是预期值', value=null, constraint='HasNotNullConstraint', expectValue='', fieldName='name'}], allList=null}

• IResult 办法阐明

返回值实现默认为 DefaultResult，接口 IResult 属性如下：

public interface IResult {    /**     * 是否全副通过验证     * @return 是否     * @since 0.1.0     */    boolean pass();    /**     * 未通过的列表信息     * @return 验证后果     * @since 0.1.0     */    List<IConstraintResult> notPassList();    /**     * 所有的验证后果列表     * @return 所有的验证后果     * @since 0.1.0     */    List<IConstraintResult> allList();    /**     * 输入信息到控台     * （1）次要是为了不便调整     * （2）该性能其实能够做加强，比方输入到文件/数据库等等。     * @return this     * @since 0.0.6     */    IResult print();    /**     * 对于未通过的信息，     * （1）未通过的界定。     *  {@link IConstraintResult#pass()} 为 false     *     * （2）内容信息     * 抛出运行时异样 {@link com.github.houbb.validator.api.exception.ValidRuntimeException}，异样信息为 {@link IConstraintResult#message()} 音讯     * （3）内容限定     *  为了防止异样内容过多，只抛出第一条即可。     *  （4）改办法的加强空间     *  4.1 能够指定什么状况下抛出异样     *  4.2 抛出异样的信息和类别     *     * @return this     * @since 0.0.6     */    IResult throwsEx();}

注解阐明

java bean 的校验，基于注解是比拟不便的。和 hibernate-validator 应用相似，这里介绍下常见的注解。

内置束缚注解

内置注解如下：

JSR-303 + hibernate-validator 束缚注解反对

条件注解

阐明

有时候咱们须要依据不同的参数，进行不同的限度条件。

比方新建时用户 id 不须要传入，然而批改时 id 必填。

如果是传统的 hibernate-validator 解决就会比拟麻烦，此处引入条件注解。

内置注解

应用

应用起来也不难，上面的成果如下：

1. operType == 'create' 时，name 的校验才会失效。
2. operType != 'create' 时，id 的校验才会失效。

其余应用形式放弃不变。

public class ConditionUser {    /**     * 操作类型     */    @Ranges({"create", "edit"})    private String operType;    /**     * 新建时，name 必填     */    @EqualsCondition(value = "create", fieldName = "operType")    @Size(min = 3)    @NotNull    private String name;    /**     * 不是新建时, id 字段必填     */    @NotEqualsCondition(value = "create", fieldName = "operType")    @Size(min = 16)    private String id;        //getter & setter}

过程式接口

阐明

日常开发中，咱们都很喜爱应用注解对 java bean 进行校验。

然而这回导致咱们定义的单个属性校验无奈复用。

所以我的项目中的单个属性校验和注解是一一对应的，为了便于复用。

ValidHelper 办法

ValidHelper 作为对立封装的工具类，提供单个办法校验常见的办法。

和 java bean 相似，办法列表：

应用例子

用法和 bean 的相似，只是入参多了第二个约束条件。

IResult result = ValidHelper.failFast("", Constraints.notEmptyConstraint());

IConstraint 对应关系

注解和常见的接口办法一一对应，所有的束缚办法在 Constraints 工具类中。

条件注解

注解和常见的接口办法一一对应，所有的束缚办法在 Conditions 工具类中。

注解自定义

阐明

内置的注解，天然无奈满足所有的场景。

本我的项目中，束缚和条件注解都是反对自定义的。

束缚注解 @Constraint

所有零碎的内置注解都能够作为学习的例子。

定义注解

以 @AllEquals 为例，外围的局部在 @Constraint(AtAllEqualsConstraint.class)。

咱们在 AtAllEqualsConstraint 中实现具体的束缚逻辑。

@Target(ElementType.FIELD)@Retention(RetentionPolicy.RUNTIME)@Constraint(AtAllEqualsConstraint.class)public @interface AllEquals {    /**     * 以后字段及其指定的字段 全副相等     * 1. 字段类型及其他字段雷同     * @return 指定的字段列表     */    String[] value();    /**     * 提醒音讯     * @return 谬误提醒     */    String message() default "";    /**     * 分组信息     * @return 分组类     * @since 0.1.2     */    Class[] group() default {};}

实现逻辑

举荐间接继承 AbstractAnnotationConstraint<A>，实现对应的逻辑即可。

public class AtAllEqualsConstraint extends AbstractAnnotationConstraint<AllEquals> {    @Override    protected IConstraint buildConstraint(AllEquals annotation) {        return Constraints.allEqualsConstraint(annotation.value());    }}

条件注解 @Condition

所有零碎的内置注解都能够作为学习的例子。

定义注解

以 @AlwaysTrueCondition 为例，外围的局部在 @Condition(AtAlwaysTrueCondition.class)。

咱们在 AtAlwaysTrueCondition 中实现具体的束缚逻辑。

@Target(ElementType.FIELD)@Retention(RetentionPolicy.RUNTIME)@Condition(AtAlwaysTrueCondition.class)public @interface AlwaysTrueCondition {}

实现逻辑

举荐间接继承 AbstractAnnotationCondition<A>，实现对应的逻辑即可。

public class AtAlwaysTrueCondition extends AbstractAnnotationCondition<AlwaysTrueCondition> {    @Override    protected ICondition buildCondition(AlwaysTrueCondition annotation) {        return Conditions.alwaysTrueCondition();    }}

开源地址

为了便于大家学习应用，目前校验框架已开源。

欢送大家 fork+star，激励一下老马~

validator