关于开源:5-年只为了一个更好的校验框架

五年前，科技大厦 1 层 B 座。

小明的眼睛直勾勾地盯着屏幕，双手噼里啪啦的敲着键盘。

思考是不存在的，思考只会让小明的速度降下来。

优良的程序员齐全不须要思考，就像不须要写文档和正文一样。

“真是简略的需要啊”，小明感觉有些无聊，“毫无挑战。”

和无数个 web 开发者一样，小明明天做的是用户的注册性能。

首先定义一下对应的用户注册对象：

public class UserRegister {

    /**
     * 名称
     */
    private String name;

    /**
     * 原始明码
     */
    private String password;

    /**
     * 确认明码
     */
    private String password2;

    /**
     * 性别
     */
    private String sex;

    // getter & setter & toString()}

注册时格局要求文档也做了简略的限度：

（1）name 名称必须介于 1-32 位之间

（2）password 明码必须介于 6-32 位之间

（3）password2 确认明码必须和 password 保持一致

（4）sex 性别必须为 BOY/GIRL 两者中的一个。

“这也不难”，有情的编码机器开始疯狂的敲打着键盘，不一会儿根本的校验办法就写好了：

private void paramCheck(UserRegister userRegister) {
    //1. 名称
    String name = userRegister.getName();
    if(name == null) {throw new IllegalArgumentException("名称不可为空");
    }
    if(name.length() < 1 || name.length() > 32) {throw new IllegalArgumentException("名称长度必须介于 1-32 之间");
    }

    //2. 明码
    String password = userRegister.getPassword();
    if(password == null) {throw new IllegalArgumentException("明码不可为空");
    }
    if(password.length() < 6 || password.length() > 32) {throw new IllegalArgumentException("明码长度必须介于 6-32 之间");
    }
    //2.2 确认明码
    String password2 = userRegister.getPassword2();
    if(!password.equals(password2)) {throw new IllegalArgumentException("确认明码必须和明码保持一致");
    }

    //3. 性别
    String sex = userRegister.getSex();
    if(!SexEnum.BOY.getCode().equals(sex) && !SexEnum.GIRL.getCode().equals(sex)) {throw new IllegalArgumentException("性别必须指定为 GIRL/BOY");
    }
}

打完出工，小明把代码提交结束，就早早地上班跑路了。

“小明啊，我明天简略地看了一下你的代码。”，项目经理看似随便地提了一句。

小明停下了手中的工作，看向项目经理，意思是让他持续说上来。

“整体还是比拟谨严的，就是写了太多的校验代码。”

“太多的校验代码？不校验数据用户乱填怎么办？”，小明有些不太明确。

“校验代码的话，有工夫能够理解一下 hibernate-validator 校验框架。”

“能够，我有工夫看下。”

嘴上说着，小明心里一万个不违心。

什么休眠框架，影响我搬砖的速度。

起初小明还是勉为其难的搜寻了一下 hibernate-validator，看了看感觉还不错。

这个框架提供了很多内置的注解，便于日常校验的开发，大大晋升了校验办法的可复用性。

于是，小明把本人的校验办法改进了一下：

public class UserRegister {

    /**
     * 名称
     */
    @NotNull(message = "名称不可为空")
    @Length(min = 1, max = 32, message = "名称长度必须介于 1-32 之间")
    private String name;

    /**
     * 原始明码
     */
    @NotNull(message = "明码不可为空不可为空")
    @Length(min = 1, max = 32, message = "明码长度必须介于 6-32 之间")
    private String password;

    /**
     * 确认明码
     */
    @NotNull(message = "确认明码不可为空不可为空")
    @Length(min = 1, max = 32, message = "确认明码必须介于 6-32 之间")
    private String password2;

    /**
     * 性别
     */
    private String sex;

}

校验办法调整如下：

private void paramCheck2(UserRegister userRegister) {
    //1. 名称
    ValidateUtil.validate(userRegister);

    //2.2 确认明码
    String password2 = userRegister.getPassword2();
    if(!userRegister.getPassword().equals(password2)) {throw new IllegalArgumentException("确认明码必须和明码保持一致");
    }

    //3. 性别
    String sex = userRegister.getSex();
    if(!SexEnum.BOY.getCode().equals(sex) && !SexEnum.GIRL.getCode().equals(sex)) {throw new IllegalArgumentException("性别必须指定为 GIRL/BOY");
    }
}

的确清新了很多，ValidateUtil 是基于一个简略的工具类：

public class ValidateUtil {

    /**
     * 应用 hibernate 的注解来进行验证
     */
    private  static Validator validator = Validation
            .byProvider(HibernateValidator.class)
            .configure().failFast(true)
            .buildValidatorFactory()
            .getValidator();

    public static <T> void validate(T t) {Set<ConstraintViolation<T>> constraintViolations = validator.validate(t);
        // 抛出测验异样
        if (constraintViolations.size() > 0) {final String msg = constraintViolations.iterator().next().getMessage();
            throw new IllegalArgumentException(msg);
        }
    }

}

然而小明仍然感觉不称心，sex 的校验能够进一步优化吗？

答案是必定的，小明发现 hibernate-validator 反对自定义注解。

这是一个很弱小的性能， 优良的框架就应该为使用者提供更多的可能性 。

于是小明实现了一个自定义注解：

@Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = MyEnumRangesValidator.class)
public @interface MyEnumRanges {Class<? extends Enum> value();

    String message() default "";}

MyEnumRangesValidator 的实现如下：

public class MyEnumRangesValidator implements
        ConstraintValidator<MyEnumRanges, String> {

    private MyEnumRanges myEnumRanges;

    @Override
    public void initialize(MyEnumRanges constraintAnnotation) {this.myEnumRanges = constraintAnnotation;}

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {return getEnumValues(myEnumRanges.value()).contains(value);
    }

    /**
     * 获取枚举值对应的信息
     *
     * @param enumClass 枚举类
     * @return 枚举阐明
     * @since 0.0.9
     */
    private List<String> getEnumValues(Class<? extends Enum> enumClass) {Enum[] enums = enumClass.getEnumConstants();

        return ArrayUtil.toList(enums, new IHandler<Enum, String>() {
            @Override
            public String handle(Enum anEnum) {return anEnum.toString();
            }
        });
    }

}

限度以后的字段值必须在指定的枚举范畴内，当前所有波及到枚举范畴的，应用这个注解即可搞定。

而后把 @MyEnumRanges 加在 sex 字段上：

@NotNull(message = "性别不可为空")
@MyEnumRanges(message = "性别必须在 BOY/GIRL 范畴内", value = SexEnum.class)
private String sex;

这样校验办法能够简化如下：

private void paramCheck3(UserRegister userRegister) {
    //1. 名称
    ValidateUtil.validate(userRegister);
    //2.2 确认明码
    String password2 = userRegister.getPassword2();
    if(!userRegister.getPassword().equals(password2)) {throw new IllegalArgumentException("确认明码必须和明码保持一致");
    }
}

小明称心的笑了笑。

然而他的笑容只是继续了一会儿，因为他发现了一个不令人满意的中央。

确认明码这一段代码能够去掉吗？

如同间接应用 hibernate-validator 框架是做不到的。

这所有令小明很苦楚，他发现框架自身的确有很多不足之处。

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

比方：

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

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

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

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

实现起来，特地简单。

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

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

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

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

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

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

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

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

于是小明花了很长时间，写了一个校验工具，心愿能够补救上述工具的有余。

开源地址：https://github.com/houbb/valid

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

<dependency>
    <groupId>com.github.houbb</groupId>
    <artifactId>valid-jsr</artifactId>
    <version>0.2.2</version>
</dependency>

工具类应用：

User user = new User();
user.sex("what").password("old").password2("new");

ValidHelper.failOverThrow(user);

报错如下：

会抛出 ValidRuntimeException 异样，异样的信息如下：

name: 值 <null> 不是预期值,password: 值 <old> 不是预期值,sex: 值 <what> 不是预期值

其中 User 的定义如下：

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 and Setter
}

内置注解简介如下：

注解	阐明
@AllEquals	以后字段及指定字段值必须全副相等
@HasNotNull	以后字段及指定字段值至多有一个不为 null
@EnumRanges	以后字段值必须在枚举属性范畴内
@Ranges	以后字段值必须在指定属性范畴内

小明在设计验证工具的时候，针对 hibernater 的有余都做了一点小小的改良。

能够让字段之间产生分割，以提供更加弱小的性能。

每一个注解都有对应的过程式办法，让你能够在注解式和过程式中切换自若。

内置了 @Condition 的注解失效条件，让注解失效更加灵便。

小明低头看了看墙上的钟，夜曾经太深了，百闻不如一见，感兴趣的小伙伴能够本人去感受一下：

开源地址：https://github.com/houbb/valid

这个开源工具是日常工作中不想写太多校验办法的产物，还处于初期阶段，还有很多须要改良的中央。

不过，心愿你能喜爱。

我是老马，期待与你的下次重逢。

关于开源:5-年只为了一个更好的校验框架

天地初开

初见 Hibernate-Validator

框架不足之处

hibernate-validator 无奈满足的场景

validation-api 过于简单

自定义不足灵活性

过程式编程 vs 注解式编程

valid 工具的诞生

个性

疾速开始

maven 引入

编码

小结