mint-validate 轻量 验证工具包
mint-validate 轻量 验证工具包
水牛叔叔 发表于3年前
mint-validate 轻量 验证工具包
  • 发表于 3年前
  • 阅读 703
  • 收藏 39
  • 点赞 2
  • 评论 15

腾讯云 十分钟定制你的第一个小程序>>>   

摘要: mint-validate 是一个轻量的 验证工具包,不含源码的jar包 9.4k,含源码的jar包 15k,一共6个java文件,无第三方依赖。validate支持自定义验证规则,并用annotation配置验证规则。它的设计借鉴了javascript 验证工具 的动态性灵活性,并采用java的反射技术实现,所以validate有较强的动态性和灵活性

工具包的结构

本工具下载地址:http://git.oschina.net/895925636/mint-validate

收录地址:http://www.oschina.net/p/mint-validate

工具包中有4个主要类,他们是Valid, Verifiable, VerificationResult, Verifier。

Valid

Valid是注解,作用在bean类的字段上,用来配置验证的参数,一共四个参数:

  1. rule。字符串数组类型,配置自定义的验证器名,名字不分大小写
  2. pattern。字符串数组类型,配置用于验证字段的正则表达式
  3. tipMsg。字符串类型。配合正则表达式验证用,当正则验证不通过是,用于提示
  4. params。字符串数组类型。配合自定义验证器使用,自定义一些定义的参数传递到验证器内部

Verifiable

Verifiable是抽象类,需要验证的bean类必须继承该类。Verifiable有两个公共方法:

  1. public final boolean validate(String... fields)。验证bean的字段,当参数中不指定字段名字时,默认验证所有可验证字段(标注有Valid的字段)。如果所有规则都验证通过,返回true;有一个规则验证不通过都将返回false。
  2. public Set<VerificationResult> getValidateResult()。获取所有的验证结果。调用validate方法做验证时,所有的规则的验证结果都会封装成Verification保存在一个Set内。该方法可以获取这些结果

VerificationResult

VerificationResult封装验证结果。记录一个验证规则的5个验证信息:

  1. fieldName。String类型,被验证字段的字段名。
  2. fieldValue。Object类型。被验证字段的值。
  3. verifier。String类型。验证该字段对应的规则名。
  4. tipMsg。String类型。自定义的验证提示信息。
  5. result。boolean类型。验证结果true or false。

Verifier

Verifier是一个接口,所有自定义验证器都需要实现该接口,并且实现他唯一的方法:public VerificationResult verify(Object bean, Class<?> fieldType, Object fieldValue, String fieldName, String[] params)。verify 方法会被Verifiable 的 validate通过反射调用。该方法5个参数的含义如下:

  1. bean。被验证的bean对象。这在二维验证时用到,比如“字段1”和“字段2” 满足一定的关系才能通过验证的情况
  2. fieldType。被验证字段的java类型。
  3. fieldValue。被验证字段的值。
  4. fieldName。被验证字段的名字。
  5. params。验证时需要用到的一些参数。比如在验证密码长度时,不能小于6个字符,又不能多于32个字符,就可以通过params指定。

方法的返回值将参考VerificationResult,返回值会被Verifiable保存,并通过Verifiable的getValidateResult获得。

工具包的用法

先亮出demo中用到的两个bean,方便起见,不写getter 和 setter。

People继承Verifiable:

package test;

import mint.validate.Valid;
import mint.validate.Verifiable;

public class People extends Verifiable{
	public int gender;
	
	@Valid(rule="notnull")
	public String address;
}

User 继承 People:

package test;

import mint.validate.Valid;

public class User extends People{
	/*采用正则表达式验证(可配置多个正则表达式)*/
	@Valid(tipMsg="邮箱地址不正确", pattern={"^[\\w-]+(\\.[\\w-]+)*@[\\w-]+(\\.[\\w-]+)+$"})
	public String email;
	
	/*简单验证器验证*/
	@Valid(rule="notnull")
	public String username;
	
	/*采用验证器验证,并给验证器传递参数*/
	@Valid(rule={"LenLimit"}, params={"6", "32"})
	public String password;
}

正则表达式验证

正则表达式验证很简单。

只要在字段上做如下配置就行,tipMsg可以不配置,正则可以配置多个:

@Valid(tipMsg="邮箱地址不正确", pattern={"^[\\w-]+(\\.[\\w-]+)*@[\\w-]+(\\.[\\w-]+)+$"})
public String email;

对象中调用validate方法就可以采用配置的正则去验证该字段了。

u.validate("email");

验证器验证

验证器验证的过程会复杂一些。一共分三步:定义验证器、注册验证器、使用验证器

定义验证器

验证器的定义需要遵循两个约定:

  1. 实现Verifier类
  2. 类名格式必须是:{验证器名字}+Verifier,验证器名字不区分大小写,比如 NotNullVerifier和NotnullVerifier是一样的。

看一个例子:

package verifiers;

import mint.validate.ValidateException;
import mint.validate.VerificationResult;
import mint.validate.Verifier;

public class LenLimitVerifier implements Verifier{
	@Override
	public VerificationResult verify(Object bean, Class<?> fieldType, Object fieldValue, String fieldName, String[] params) {
		if(fieldValue == null) return new VerificationResult(fieldName, "lenlimit", "字段值为空",	 null, false);
		
		if(params.length < 2){
			throw new ValidateException("没有指定合适参数");
		}
		
		int min, max;
		try{
			min = Integer.parseInt(params[0]); 
			max = Integer.parseInt(params[1]);
		} catch (NumberFormatException e){
			e.printStackTrace();
			throw new ValidateException("参数格式错误,无法转换成数字");
		}
		
		int len = ((String)fieldValue).length();
		if(len < min){
			return new VerificationResult(fieldName, "lenlimit", fieldName+"不能少于"+min+"个字符", fieldValue, false);
		}
		
		if(len > max){
			return new VerificationResult(fieldName, "lenlimit", fieldName+"不能多于"+max+"个字符", fieldValue, false);
		}
		return null;
	}
}
以上一个验证器的名字是LenLimit(使用时不区分大小写),用于验证一个String 字段的长度不能小于6字符而且不能大于32字符。

注册验证器

注册验证器需要在class目录下创建一个properties文件。如下图:

里面只写一个属性packages,属性值是自定义验证器所在的包,多个包用“;”(英文分号)隔开。like this:

packages=verifiers
这样验证工具在启动时就会自动去指定的包下扫描自定义验证器了。

使用验证器

这一步跟正则表达式的用法差不多,就在对应的字段上配置验证器:

/*采用验证器验证,并给验证器传递参数*/
@Valid(rule={"LenLimit"}, params={"6", "32"})
public String password;
因为LenLimitVerifier是验证长度限制的,所以用params配置两个表示长度限制的参数。

调用验证:

User u = new User();
u.password = "passw";
System.out.println(u.validate("password"));
for(VerificationResult r : u.getValidateResult()){
	System.out.println(r);
}

查看结果:

ps:自定义验证器灵活功能强,可以二维验证,可以结合数据库验证,反正逻辑随你写。

再写两个例子作为结束

验证父类中的字段。address字段在父类People中:

User u = new User();
u.address = "中国广东";
u.validate("address");
for(VerificationResult r : u.getValidateResult()){
    System.out.println(r);
}
验证所有配置了Valid注解的字段:
User u = new User();
		
u.email = "895925636#qq.com";
u.password = "passw";
u.address = "中国广东";

/*不写字段名*/
u.validate();
		
for(VerificationResult r : u.getValidateResult()){
	System.out.println(r);
}
欢迎讨论指正。。。
共有 人打赏支持
水牛叔叔
粉丝 138
博文 72
码字总数 36149
作品 2
评论 (15)
静心天涯
好好地看了一下源码,感觉写得很棒(比我自己想得,好很多)。如果说,有可以改进的地方,我暂时想得有这些(不一定正确,纯属推测):
1、Verifiable#init() 关闭 InputStream
2、如果是按照原有的设计思想 ——“获取全局验证结果,失败的验证和成功的验证”,那在写对应的验证规则时,不应该是返回 null,而是返回正确的验证提示。
3、关于在群里提到那个 tipMsg 的国际化,这个实现起来总觉得怪怪的。我的思路,是直接写一个 properties来记录tipMsgs,感觉怪的地方就是,一时写在注解,一时写在 配置文件,觉得有点不是很好。
4、关于那个继承Verifiable 的问题,我觉得可以这样做。去掉这个继承,在 Verifiable#validate 方法里增减一个参数 clazz(用来获取当前类需要验证的字段),如果是这样的,那 Verifiable 里 results 和 globalResult 变量需要改变一下才行。在调用的时候,Verifiable.validate(clazz,field1,field2...)。 不知道这样是否可以。
zmf
学习了,不过有个疑问:就是软引用那块好像有点问题,Map<String, SoftReference<Map<String, FieldInfo>>>这样申明觉得有个问题:1.就算软引用实例回收了,map对象的内存也没完全释放有点浪费,这样SoftReference<Map<String, Map<String, FieldInfo>>>是不是好点
2.虽然软引用实例Map<String, FieldInfo>内存回收了,但是软引用SoftReference可能还在,需要ReferenceQueue监听poll()删除该SoftReference.get()==null
水牛叔叔

引用来自“zmf”的评论

学习了,不过有个疑问:就是软引用那块好像有点问题,Map<String, SoftReference<Map<String, FieldInfo>>>这样申明觉得有个问题:1.就算软引用实例回收了,map对象的内存也没完全释放有点浪费,这样SoftReference<Map<String, Map<String, FieldInfo>>>是不是好点
2.虽然软引用实例Map<String, FieldInfo>内存回收了,但是软引用SoftReference可能还在,需要ReferenceQueue监听poll()删除该SoftReference.get()==null
好!我忽略了这一点,而且你的那个解决方案简直一流,我去改一下。谢谢哥们了
水牛叔叔

引用来自“静心天涯”的评论

好好地看了一下源码,感觉写得很棒(比我自己想得,好很多)。如果说,有可以改进的地方,我暂时想得有这些(不一定正确,纯属推测):
1、Verifiable#init() 关闭 InputStream
2、如果是按照原有的设计思想 ——“获取全局验证结果,失败的验证和成功的验证”,那在写对应的验证规则时,不应该是返回 null,而是返回正确的验证提示。
3、关于在群里提到那个 tipMsg 的国际化,这个实现起来总觉得怪怪的。我的思路,是直接写一个 properties来记录tipMsgs,感觉怪的地方就是,一时写在注解,一时写在 配置文件,觉得有点不是很好。
4、关于那个继承Verifiable 的问题,我觉得可以这样做。去掉这个继承,在 Verifiable#validate 方法里增减一个参数 clazz(用来获取当前类需要验证的字段),如果是这样的,那 Verifiable 里 results 和 globalResult 变量需要改变一下才行。在调用的时候,Verifiable.validate(clazz,field1,field2...)。 不知道这样是否可以。
1、我还真的忘记关闭流了,这是一个严重的错误,谢谢指出
2、这个看自己的需要吧,这个工具主要是提防些试图绕过前端验证,直接修改页面代码或者伪造请求的孩童破坏后台数据用的。我现在一般只返回 true or false,甚至详细信息都不返回给他,详细信息只是后台自己看的,因为我已经假设提交错误数据到后台的孩童是故意搞破坏的,哈哈。当然你可以对他们好点,告诉他们哪对哪错
3、这个工具一开始只是为了个人方便而写的,真的没考虑到国际化的问题,因为我的构想是很小的。如果真的要国际化的话,在自定义规则里应该挺好实现的,因为里面逻辑完全由开发者把握。但是在正则验证时就不好实现了,因为正则验证tipMsg是写死在Annotation里面的。所以如果想国际化,就都把正则验证也写到自定义规则就可以了
4、这个问题我也纠结。但是基于我写代码的理念——“思路直接,简单而好”——我只能做样做了。以前我看别的断言工具就是你说的这么写的,但是我觉得用户体验不是很好,比如这样:Assert(bean, field1, field2)。这个纯属个人爱好 哈 谢谢你的讨论,哈哈
水牛叔叔

引用来自“静心天涯”的评论

好好地看了一下源码,感觉写得很棒(比我自己想得,好很多)。如果说,有可以改进的地方,我暂时想得有这些(不一定正确,纯属推测):
1、Verifiable#init() 关闭 InputStream
2、如果是按照原有的设计思想 ——“获取全局验证结果,失败的验证和成功的验证”,那在写对应的验证规则时,不应该是返回 null,而是返回正确的验证提示。
3、关于在群里提到那个 tipMsg 的国际化,这个实现起来总觉得怪怪的。我的思路,是直接写一个 properties来记录tipMsgs,感觉怪的地方就是,一时写在注解,一时写在 配置文件,觉得有点不是很好。
4、关于那个继承Verifiable 的问题,我觉得可以这样做。去掉这个继承,在 Verifiable#validate 方法里增减一个参数 clazz(用来获取当前类需要验证的字段),如果是这样的,那 Verifiable 里 results 和 globalResult 变量需要改变一下才行。在调用的时候,Verifiable.validate(clazz,field1,field2...)。 不知道这样是否可以。
博客的评论还真的要写“
”才能换行
水牛叔叔
我的“<br/<”被吞了
朱宏青
你可以看看JSR303
定义:javax.validation.*
实现:hibernate-validator-4.1.0.Final
资料:http://www.ibm.com/developerworks/cn/java/j-lo-beanvalid/
水牛叔叔

引用来自“朱宏青”的评论

你可以看看JSR303
定义:javax.validation.*
实现:hibernate-validator-4.1.0.Final
资料:http://www.ibm.com/developerworks/cn/java/j-lo-beanvalid/
非常好,我之前对这个了解不深,只是见别人用过。那个资料我看了,但是还是嫌这个规范的注解过多,不够灵活。欢迎探讨
NewAE
水牛 我感觉不错嘛..感觉挺灵活的..
开源中国首席脑科主任
应该不支持国际化
开源中国首席脑科主任
应该不支持国际化
开源中国首席脑科主任
还有一种情况,就是同样操作一个实体类,在2中不同的业务下,也许有些字段验证会不同,要是能解决这些细节就完美了,spring有专门的验证框架我用过,原理你和他的差不多。赞!
水牛叔叔

引用来自“Kings__”的评论

还有一种情况,就是同样操作一个实体类,在2中不同的业务下,也许有些字段验证会不同,要是能解决这些细节就完美了,spring有专门的验证框架我用过,原理你和他的差不多。赞!
如果要根据业务的不同而区别验证规则,可以给自定义的规则传参数,这样可以一定程度解决这个问题。
水牛叔叔

引用来自“zmf”的评论

学习了,不过有个疑问:就是软引用那块好像有点问题,Map<String, SoftReference<Map<String, FieldInfo>>>这样申明觉得有个问题:1.就算软引用实例回收了,map对象的内存也没完全释放有点浪费,这样SoftReference<Map<String, Map<String, FieldInfo>>>是不是好点
2.虽然软引用实例Map<String, FieldInfo>内存回收了,但是软引用SoftReference可能还在,需要ReferenceQueue监听poll()删除该SoftReference.get()==null
哥们你说的那个问题真的存在,今天就出问题了,我还专程来看这个评论找解决方案。非常的感谢
sp42
不错啊 有点像 Hibernate Validator,但 Hibernate Validator 十多兆。我用 Apache BVal,http://blog.csdn.net/zhangxin09/article/details/50600575。兼容 JSR 303 更好
×
水牛叔叔
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: