写在前面
相信很多经历了项目的人,会发现几乎没有哪个项目不需要验证的。在经历过多个项目之后,有感于项目中使用最多的验证方式,这里写了一个基于java反射机制的验证框架。该框架适用于对javaBean中的属性通过java反射机制获取对应的值和用户直接传入的值来进行各种规则的验证。由于其几乎不依赖任何第三方jar包,因此可以适用所有java项目中。
开始使用
1、由于这些代码是在JDK1.5环境下编写的,用到了JDK1.5中的一些高级特性(如泛型等),因此使用该框架的项目最好是基于JDK1.5及以上版本的。
2、使用方式。
在这个框架中,整个使用的入口就是一个工具类:com.cloudframework.validation.ValidatorUtils。具体使用示例如下(示例代码在com.cloudframework.validation.sample.Demo):
DemoEntity de = new DemoEntity();//DemoEntity是一个javaBean。
// 普通使用
CloudBindingResult result = ValidatorUtils.validateEntity(de, "str", NotEmptyRule.class);
System.out.println(result.getFieldErrorMessage("str"));
// 自定义验证信息
result = ValidatorUtils.validateEntity(de, "str", new NotEmptyRule("这里是指定验证信息示范!"));
System.out.println(result.getFieldErrorMessage("str"));
// 同时验证两个属性
result = ValidatorUtils.validateEntity(de, "num,date", NotNullRule.class);
System.out.println(result.getFieldErrorMessage("num") + " || " + result.getFieldErrorMessage("date"));
// 使用多个验证规则
result = ValidatorUtils.validateEntity(de, "str", NotEmptyRule.class, SingleEmailRule.class);
System.out.println(result.getFieldErrorMessage("str"));// 这里注意其打印出来的验证信息!
// 多个属性同时使用多个规则
result = ValidatorUtils.validateEntity(de, "str,col", NotEmptyRule.class, SingleEmailRule.class);
System.out.println(result.getFieldErrorMessage("str") + " || " + result.getFieldErrorMessage("col"));
其运行结果为:
不能为空!
这里是指定验证信息示范!
不能为空! || 不能为空!
不能为空!;邮箱格式不正确!
不能为空!;邮箱格式不正确! || 不能为空!;邮箱格式不正确!
3、 需要注意的是,有时候,我们需要验证一个单独的字符串或数字是否符合某个规则,这时候,这样的值并不是javaBean中的值,在这样的情况下,ValidatorUtils中的validateValue方法正是解决这样的单独验证的,它是可以直接验证给定的内容的。示例如下:
// 注意下面方法的返回值,是String类型。
System.out.println(ValidatorUtils.validateValue("hello",NotEmptyRule.class,SingleEmail.class));
System.out.println(ValidatorUtils.validateValue("",NotEmptyRule.class,SingleEmail.class));
System.out.println(ValidatorUtils.validateValue(null,NotEmptyRule.class,SingleEmail.class));
System.out.println(ValidatorUtils.validateValue("hello",NotEmptyRule.class));
其运行结果如下:
邮箱格式不正确!
不能为空!;邮箱格式不正确!
不能为空!;邮箱格式不正确!
自定义规则
在上面的使用中,我们用到了这些规则:NotEmptyRule、NotNullRule、SingleEmailRule。这些规则是我已经在框架中提供的仅有的三种规则!对于业务复杂、规则众多的情况下,用户可以自己扩展这些规则。扩展的方式为:新建一个类,并实现自com.cloudframework.validation.rules.ValidateRule接口。该接口代码如下:
package com.cloudframework.validation.rules;
/**
* 验证规则的接口。所有的具体验证规则都实现自这个接口。
*
* @author taofucheng
*
*/
public interface ValidateRule {
/**
* 进行具体规则的验证逻辑。
*
* @param value
* 具体的验证内容。
* @return true:验证通过;false:验证不通过
*/
public boolean validate(Object value);
/**
* 获取验证不通过时的报错信息。如果用户指定的验证信息为空,则返回默认的报错信息。
*
* @return 返回验证的报错信息
*/
public String getValidateInfo();
}
具体实现和规则的使用的示例可以参考现有的这三个规则类(NotEmptyRule、NotNullRule、SingleEmailRule)。
设计
在整个框架的设计中,其设计思路很简单:调用入口到反射取值,调用规则验证。其UML图可示例如下(使用StarUML作图):
设计思想与各关系上图中已经详细表明了,这里就不赘述了。
后记
现有的不足
字段名称不宜控制。现在的使用方式为:ValidatorUtils.validateEntity(entity, "field1", NotEmptyRule.class),其中字段名称是用户传入的字符串,如果该实体中的字符串名称发生改变,则这里是无法知晓的!也就是说,这里会因为实体中的字段名称变化而形成一个极隐蔽的隐患!
可扩展为注解
在现在这个年头,注解(annotation)似乎已经很被大众接受,同时也流行开了,从Spring到Hibernate,再到Struts……
在注解风靡的现在,如果这个验证框架没有注解使用方式估计会少了一席战场吧。由于本人急于使用,再加上最近也一直很忙,静不下心来完善,所以上面提到的注解功能就一直没写。其实,注解的实现很简单,建议大家可以参考一下Hibernate validator框架,我觉得这个验证框架很不错,它是完全基于注解的。我也会在后面的某一天将注解的内容补充完整。
补充
1、 对于验证中的字段名称随实体改变而不会留下隐患,我一直找不到一个好的办法解决。想想除了用注解的方式,还真没找到一个合适的方式。
2、 对于注解的使用,我个人认为对于代码的侵入性比较强。我想这也许就是为什么很多人对注解有一定的抵触情绪吧。
3、 这个验证框架,只是依赖于commons-lang.jar包,但只用到了其中的StringUtils类,如果将该类中用到的功能自己实现的话,可以不依赖于任何jar包了!