基于java反射的验证框架

关注

最新推荐文章于 2026-02-07 10:00:00 发布 155 阅读 AI 写同款· GEO 优化 ›

写在前面

相信很多经历了项目的人，会发现几乎没有哪个项目不需要验证的。在经历过多个项目之后，有感于项目中使用最多的验证方式，这里写了一个基于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作图）：
UML图

设计思想与各关系上图中已经详细表明了，这里就不赘述了。

后记

现有的不足

字段名称不宜控制。现在的使用方式为：ValidatorUtils.validateEntity(entity, "field1", NotEmptyRule.class)，其中字段名称是用户传入的字符串，如果该实体中的字符串名称发生改变，则这里是无法知晓的！也就是说，这里会因为实体中的字段名称变化而形成一个极隐蔽的隐患！

可扩展为注解

在现在这个年头，注解（annotation）似乎已经很被大众接受，同时也流行开了，从Spring到Hibernate，再到Struts……
在注解风靡的现在，如果这个验证框架没有注解使用方式估计会少了一席战场吧。由于本人急于使用，再加上最近也一直很忙，静不下心来完善，所以上面提到的注解功能就一直没写。其实，注解的实现很简单，建议大家可以参考一下Hibernate validator框架，我觉得这个验证框架很不错，它是完全基于注解的。我也会在后面的某一天将注解的内容补充完整。

补充

1、对于验证中的字段名称随实体改变而不会留下隐患，我一直找不到一个好的办法解决。想想除了用注解的方式，还真没找到一个合适的方式。
2、对于注解的使用，我个人认为对于代码的侵入性比较强。我想这也许就是为什么很多人对注解有一定的抵触情绪吧。
3、这个验证框架，只是依赖于commons-lang.jar包，但只用到了其中的StringUtils类，如果将该类中用到的功能自己实现的话，可以不依赖于任何jar包了！

收录于