看看Hibernate Validator 是怎么做的吧.一见到她,相信你就会说: Oh God, 这就是我需要的.

任何获得Matrix授权的网站，转载请保留以下作者信息和链接：
作者：icess(作者的blog:http://blog.matrix.org.cn/page/icess)
关键字：Hibernate Validator

用Annotations 给类或者类的属性加上约束(constraint),在运行期检查属性值是很优雅的.Hibernate Validator就是这样的一个框架.该框架是十分容易的(就像参考文档中宣称的那样),几乎没有什么学习曲线,Validator 是一个验证框架 不需要和Hibernate的其他部分绑定就可以使用,只要在你的项目中添加Hibernate-annotations.jar库就可以了.那么下面就让我们看看怎么使用吧.

Person.java 类

/*
  * Created on 2006-1-12 Person.java
  * @author 
  */
package  test.annotation.validator;

import  org.hibernate.validator.Length;
import  org.hibernate.validator.Min;
import  org.hibernate.validator.Valid;
　

//@Serializability  //测试自定义约束
public class  Person {

   private  String name;
   private int  age;
   private  Address address;
  
   public  Person() {}
  
   @Valid //注意此处
   public  Address getAddress() {
     return  address;
   }
   public void  setAddress(Address address) {
     this .address = address;
   }
  
   @Min(value =  1 )
   public int  getAge() {
     return  age;
   }
   public void  setAge( int  age) {
     this .age = age;
   }
  
   @Length(min =  4 )
   public  String getName() {
     return  name;
   }
   public void  setName(String name) {
     this .name = name;
   }
}

Address.java 类

/*
  * Created on 2006-1-12 Address.java
  * @author 
  */
package  test.annotation.validator;

import  org.hibernate.validator.Length;
import  org.hibernate.validator.Max;
import  org.hibernate.validator.Min;

public class  Address {

   private  String street;
   private int  num;
  
   public  Address() {}
  
   @Min(value =  1 )
   @Max(value =  100 )
   public int  getNum() {
     return  num;
   }
   public void  setNum( int  num) {
     this .num = num;
   }
  
   @Length(min =  3 ,max =  8 )
   public  String getStreet() {
     return  street;
   }
   public void  setStreet(String street) {
     this .street = street;
   }
}

TestValidator.java 类

/*
  * Created on 2006-1-12
  * @author icerain
  */
package  test.annotation.validator;

import  org.hibernate.validator.ClassValidator;
import  org.hibernate.validator.InvalidValue;


public class  TestValidator {
   public void  test() {
     Address add =  new  Address();
     add.setNum( 0 );
     add.setStreet( "1" );
    
     Person p =  new  Person();
     p.setAddress(add);
     p.setAge( 0 );
     p.setName( "ice" );
    
     /******************Test validator ********/

    // 注意该处只验证了Person 为了说明 @Valid 注释的使用
     ClassValidator<Person> classValidator =  new  ClassValidator<Person> (Person. class );
     InvalidValue[] validMessages = classValidator.getInvalidValues(p);
     for  (InvalidValue value : validMessages) {
      
     System.out.println( "InvalidValue 的长度是:"  + validMessages.length
         + " . 验证消息是: "  + value.getMessage() 
         +  " . PropertyPath 是:"  + value.getPropertyPath()
         + " .\n\t PropertyName 是: "  +value.getPropertyName()
         +  "Value 是: "  + value.getValue()
         + " Bean 是: " + value.getBean()
         + "\n\t BeanClass 是:"  + value.getBeanClass());
     }
   }
  
   public static void  main(String[] args) {
     new  TestValidator().test();
   }
}

程序的输出如下

InvalidValue 的长度是:4 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@dd87b2

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:4 . 验证消息是: 长度必须介于 4 与 2147483647 之间 . PropertyPath 是:name .

PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@dd87b2

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:4 . 验证消息是: 必须大于等于 1 . PropertyPath 是:address.num .

PropertyName 是: num. Value 是: 0 Bean 是: test.annotation.validator.Address@197d257

BeanClass 是:class test.annotation.validator.Address

InvalidValue 的长度是:4 . 验证消息是: 长度必须介于 3 与 8 之间 . PropertyPath 是:address.street .

PropertyName 是: street. Value 是: 1 Bean 是: test.annotation.validator.Address@197d257

BeanClass 是:class test.annotation.validator.Address

可以看出不满足约束的值都被指出了.

同时该句: ClassValidator<Person> classValidator = new ClassValidator<Person> (Person.class);

我们只验证了 Person. 在Person里面的Address的属性 由于有@Valid Annotations 所以 Address的相关属性也被机联验证了 .

如果 把@Valid Annotations 去掉,结果如下:

InvalidValue 的长度是:2 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@18fef3d

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:2 . 验证消息是: 长度必须介于 4 与 2147483647 之间 . PropertyPath 是:name .

PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@18fef3d

BeanClass 是:class test.annotation.validator.Person

可以看出 没有验证 Address.

当然了 ,你还可以只验证一个属性 , 没有必要验证整个类.只需要在调用 classValidator.getInvalidValues(p,"age")方法时 加上你要验证的属性就可以了.如我们只想验证age 属性 把代码改为如下所示:

InvalidValue[] validMessages = classValidator.getInvalidValues(p,"age"); / /只验证age 属性

运行结果如下:

InvalidValue 的长度是:1 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@1457cb

BeanClass 是:class test.annotation.validator.Person

只是验证了 age 属性.

怎么样 ,很简单吧. 关于 Hibernate Validator 内建的验证Annotations 大家可以看看 API 或者 参考文档(中文版我正在翻译中 请访问我的 Blog 获得最新信息).

如果你要写自己的约束呢 , 你不用担心 ,这也是很容易的. 任何约束有两部分组成: [约束描述符 即注释]the constraint descriptor (the annotation) 和[约束validator 即 实现类] the constraint validator (the implementation class).下面我们扩展Hibernate Test suit 中的一个Test 来讲解一下.

@ValidatorClass(SerializabilityValidator. class ) 指出了 constraint validator 类.

@Target({METHOD,FIELD,TYPE})
@Retention(RUNTIME)
@Documented                

这几个我就不用解释了吧.

Serializability 里面声明了一个 message 显示约束的提示信息. num 只是为了说明一个方面 在这里面没有实际用途用 .

然后就是 实现一个 constraint validator 类 该类要实现Validator<ConstraintAnnotation>.这里是SerializabilityValidator.java 如下:

//$Id: SerializabilityValidator.java,v 1.3 2005/11/17 18:12:11 epbernard Exp $
package  test.annotation.validator;

import  java.io.Serializable;

import  org.hibernate.validator.Validator;

/**
  * Sample of a bean-level validator
  *
  *  @author  Emmanuel Bernard
  */
public class  SerializabilityValidator  implements  Validator<Serializability>, Serializable {
   public boolean  isValid(Object value) {
    //这里只是Validator 里面的 实现验证规则的 方法. value 是要验证的值.
     System.out.println( "IN SerializabilityValidator isValid:" +value.getClass()+ ": "  +value.toString());
     return  value instanceof Serializable;
  }

  public void initialize(Serializability parameters) {
    // 在这里可以 取得 constraint descriptor 里面的属性 如上面我们声明的 num
     System.out.println( "IN SerializabilityValidator: parameters:" + parameters.num() );
   }
}

然后在你的类中应用@Serializability  就可以约束一个类实现Serializable 接口了. 如下:

在我们的Person.java类 添加@Serializability  Annotations ,把Person.java 中的 //@Serializability //测试自定义约束 注释去掉就ok了.

运行结果如下:

InvalidValue 的长度是:3 . 验证消息是: bean must be serialiable . PropertyPath 是:null .

现在把Person类实现 java.io.Serializable 接口 则没有出现 验证错误消息.

消息的国际化也是很简单的,把 Serializability  中的message 改为以{}扩住的 属性文件的Key就可以了

public  @interface Serializability {
   int  num()  default  11 ;
   String message()  default  "{Serializable}"; //"bean must be serialiable"; //消息的国际化
}

然后编辑资料文件. 注意 该资源文件中要包括 Hibernate Validator 内建的资源. 可以在该org\hibernate\validator\resources 包里面的资源文件基础上修改 ,在打包里面 这样就可以了. 自己打包可能不太方便.你可以把该包里面的文件复制出来.然后放到你自己的项目包下在自己编辑, 该测试中 我是放在 test\resources 包下的.

然后在 资源文件中添加 Serializable = '''''' 这么一行, 样例如下:

#DefaultValidatorMessages.properties (DefaultValidatorMessages_zh.properties 不再列出^_^)

#下面是 Hibernate Validator 内建的国际化消息

validator.assertFalse= assertion failed

validator.assertTrue= assertion failed

validator.future= must be a future date

validator.length= length must be between {min} and {max}

validator.max= must be less than or equal to {value}

validator.min= must be greater than or equal to {value}

validator.notNull= may not be null

validator.past= must be a past date

validator.pattern= must match "{regex}"

validator.range= must be between {min} and {max}

validator.size= size must be between {min} and {max}

#下面是自定义的消息

Serializable= Bean not Serializable  //加上自己定义的国际化消息.

在构造 ClassValidator 时要添上 资源文件 如下:(在测试类中)

ClassValidator<Person> classValidator = new ClassValidator<Person> (Person.class,ResourceBundle.getBundle("test.resources.DefaultValidatorMessages"));//加载资源

这样就可以了 .  当然 你还可以 更改 Hibernate Validator 的消息(不是在上面的资源文件中直接修改 validator.length = ... 等等 ) , 还记得 Validator 注释中有个 message 元素吗? 你以前用的都是默认值,现在你可以该为你自己定义的了. 如:validator.length 我把他改为 "该字符串的长度不符合规定范围范围". 在资源文件中添加一行键值属性对(key定义为 "myMsg")如下:

myMsg=该字符串的长度不符合规定范围范围

并且还要在 @Length 注释中提供message的引用的key 如下 @Length(min = 4,message = "{ myMsg }")

再一次运行测试 ,我们就可以看到上面两条自定义绑定的消息了 .如下:

InvalidValue 的长度是:3 . 验证消息是: Bean 不是 可 Serializable . PropertyPath 是:null .
PropertyName 是: null. Value 是: test.annotation.validator.Person@1bd4722 Bean 是: test.annotation.validator.Person@1bd4722
BeanClass 是:class test.annotation.validator.Person


InvalidValue 的长度是:3 . 验证消息是: 该字符串的长度不符合规定范围范围 . PropertyPath 是:name .
PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@1bd4722
BeanClass 是:class test.annotation.validator.Person

怎么样,比你想象的简单吧.

OK 上面我们讨论了 Hibernate Validator 的主要用法: 但是 该框架有什么用呢? ^_^

看到这里其实不用我在多说了 大家都知道怎么用,什么时候用. 作为一篇介绍性文章我还是在此给出一个最常用的例子吧,更好的使用方式大家慢慢挖掘吧.

比如 : 你现在在开发一个人力资源(HR)系统 (其实是我们ERP课程的一个作业 ^_^), 里面要处理大量的数据,尤其是在输入各种资料时 如 登记员工信息. 如果你公司的员工的年龄要求是18 -- 60 那么你所输入的年龄就不能超出这个范围. 你可能会说这很容易啊 , 不用Validator就可以解决啊.这保持数据前验证就可以啦 如if ( e.getAge() > 60 || e.getAge() < 18 ) ........ 给出错误信息 然后提示重新输入不就OK啦 用得着 兴师动众的来个第三方框架吗?

是啊 当就验证这一个属性时, 没有必要啊 ! 但是一个真正的HR 系统,会只有一个属性要验证吗? 恐怕要有N多吧

你要是每一个都那样 写一段验证代码 是不是很烦啊 ,况且也不方便代码重用. 现在考虑一些 Validator 是不是更高效啊,拦截到 约束违例的 属性 就可以直接得到 国际化的消息 可以把该消息显示到一个弹出对话框上 提示更正  !

Validator的用处不只这一种 ,你可以想到如何用呢 ! 欢迎发表你的高见!!

OK 到此 我们的 Hibernate Validator 之旅就要先告一段落了 . 希望这是令你心旷神怡的一次寒冬之旅,

把你学到的应用到你的项目中吧,一定会提高你的生产率的. 相信我 ,没错的  ^_^ !

任何获得Matrix授权的网站，转载请保留以下作者信息和链接：
作者：icess(作者的blog:http://blog.matrix.org.cn/page/icess)
关键字：Hibernate Validator

我在前面一篇文章<Hibernate Annotations 实战-- 从 hbm.xml 到 Annotations>:

中,有很多开发者在谈论中提到,有没有必要从 hbm.xml 往 Annotations 上转移. 那么在这篇文章中我们就来讨论一下 hbm.xml 与 Annotations的优缺点,看看那种情况最适合你.

首先,讨论一下 xml 配置文件的优点, 个人认为主要优点就是当你改变底层配置时 不需要改变和重新编译代码,只需要在xml 中更改就可以了,例如 Hibernate.cfg.xml 当你要更改底层数据库时, 只要更改配置文件就可以了.Hibernate会为你做好别的事情.

那么xml的缺点呢,个人认为有以下几点:

下面我们看看 Annotations的 特性吧! 可以解决xml遇到的问题,有以下优点

这一行, 因为在前面的实验中以及建立了数据库表了 不再需要更新了.如果你是第一次运行该例子 还是要该行的.

Test.java 如下:

/*
 * Created on 2005
 * @author 
 */
package test.hibernate.annotation;

import org.hibernate.Session;
import org.hibernate.Transaction;

public class Test {
  
  public static void main(String [] args) {
    long start = 0;
    long end = 0;
    start = System.currentTimeMillis();  //程序开始时间
    
    Session s = HibernateUtil.currentSession();
    long mid =  System.currentTimeMillis();  //初始化完毕的时间 (可能此时并没有初始化完毕^_^)
    
    Transaction tx = s.beginTransaction();    
    /********************测试读取的代码************************/
    Person p = null;
    for(int i = 1; i <= 100; i ++) {
    p = (Person) s.get(Person.class, i);
    System.out.println(p.getName());
    }
    System.out.println(p.getName());

    /********************测试读取1次的代码************************/
    Person p = null;
    p = (Person) s.get(Person.class, 1);
    System.out.println(p.getName());
    /*********************测试插入的代码*************************************/
    /*
    for (int i = 0; i < 100; i ++) {
      Person p = new Person();
      p.setAge(i+1);
      p.setName("icerain"+i);
      p.setSex("male"+i);
      s.save(p);
      s.flush();
    }
    */
    tx.commit();
    HibernateUtil.closeSession();
    
    end = System.currentTimeMillis(); //测试结束时间
    System.out.println("String[] - start time: " + start);
    System.out.println("String[] - end time: " + end);
    System.out.println("Init time : " + (mid-start)); // 打印初始化用的时间
    System.out.println("Last time is :" +(end - mid) ); //打印 数据操作的时间
    System.out.println("Total time : " +(end - start)); //打印总时间
  }
}

Annotations 包中的Person.java 如下

package test.hibernate.annotation;

import java.util.LinkedList;
import java.util.List;

import javax.persistence.AccessType;
import javax.persistence.Basic;
import javax.persistence.Entity;
import javax.persistence.GeneratorType;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Transient;

/**
 * Person generated by hbm2java
 */

@SuppressWarnings("serial")
@Entity(access = AccessType.PROPERTY)
@Table
public class Person implements java.io.Serializable {
  private Integer id;
  private String name;
  private String sex;
  private Integer age;
  private List list = new LinkedList();

  // Constructors
  /** default constructor */
  public Person() {
  }

  /** constructor with id */
  public Person(Integer id) {
    this.id = id;
  }

  // Property accessors
  @Id(generate=GeneratorType.AUTO)
  public Integer getId() {
    return this.id;
  }

  public void setId(Integer id) {
    this.id = id;
  }

  @Basic
  public String getName() {
    return this.name;
  }

  public void setName(String name) {
    this.name = name;
  }

  @Basic
  public String getSex() {
    return this.sex;
  }

  public void setSex(String sex) {
    this.sex = sex;
  }

  @Basic
  public Integer getAge() {
    return this.age;
  }

  public void setAge(Integer age) {
    this.age = age;
  }
  @Transient
  public List getList() {
    return list;
  }
  public void setList(List list) {
    this.list = list;
  }

}

其他的代码几乎没有改变:

下面的每种类型的测试都测试了3次以上, 取中间的测试时间.

测试机器配置:

CPU:  AMD Athlon (xp) 2000+

内存: 784880KB

硬盘: 三星 SP0812N

读取一次  的比较:(单位: 毫秒)

   读取100次的比较:

插入100次的比较:

从上面的三次对比中大家可以看到 初始化的部分几乎两者是一样的, 在数据操作上面 使用xml文件 总是比使用Annotations 慢一点.在我们只操纵一个只有几个属性的小持久化类的操作中就有 几十毫秒的差距. 几十毫秒在计算机中算不算很大 大家应该都知道,我就不在多说了.

总结: 经过 xml 文件 和Annotations 的优缺点和 性能上的对比.现在使用那个作为你持久化映射策略.我相信大家都会正确选择的.

测试后记: 经过多次测试 感觉有时候很不稳定 ,有的时候很稳定不知道是测试有问题还是别的问题.大家可以自己测试一下. 有什么新的发现 请大家讨论讨论.

								import java.io.Serializable;

import net.sf.hibernate.HibernateException;
import net.sf.hibernate.Session;
import net.sf.hibernate.SessionFactory;
import net.sf.hibernate.Transaction;

public class HibernateSessionUtil implements Serializable
{
publicstaticfinal ThreadLocal tLocalsess = new ThreadLocal();

publicstaticfinal ThreadLocal tLocaltx = new ThreadLocal();

    /*
     * getting the thread-safe session for using
     */
publicstatic Session currentSession(){
        Session session = (Session) tLocalsess.get();

//open a new one, if none can be found.
try{
if (session == null){
                session = openSession();
                tLocalsess.set(session);
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
return session;
    }

    /*
     * closing the thread-safe session
     */
publicstatic void closeSession(){

        Session session = (Session) tLocalsess.get();
        tLocalsess.set(null);
try{
if (session != null && session.isOpen()){
                session.close();
            }

        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * begin the transaction
     */
publicstatic void beginTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
if (tx == null){
                tx = currentSession().beginTransaction();
                tLocaltx.set(tx);
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * close the transaction
     */
publicstatic void commitTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
if (tx != null && !tx.wasCommitted() && !tx.wasRolledBack())
                tx.commit();
            tLocaltx.set(null);
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * for rollbacking
     */
publicstatic void rollbackTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
            tLocaltx.set(null);
if (tx != null && !tx.wasCommitted() && !tx.wasRolledBack()){
                tx.rollback();
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

privatestatic Session openSession() throws HibernateException{
return getSessionFactory().openSession();
    }

privatestatic SessionFactory getSessionFactory() throws HibernateException{
return SingletonSessionFactory.getInstance();
    }
}

　filter中的程式碼如下

								public class HibernateSessionCloser implements Filter{

protected FilterConfig filterConfig = null;

public void init(FilterConfig filterConfig)throws ServletException{
this.filterConfig = filterConfig;
    }

public void destroy(){
this.filterConfig = null;
    }    

public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain)
throws IOException, ServletException {
try{
            chain.doFilter(request, response);
        }
finally{
try{
                HibernateSessionUtil.commitTransaction();
            }catch (InfrastructureException e){
                HibernateSessionUtil.rollbackTransaction();
            }finally{
                HibernateSessionUtil.closeSession();
            }   
        }

    }
}

然後在操作資料庫之前加上

HibernateSessionUtil.beginTransaction();
HibernateSessionUtil.currentSession();//取得Session

利用Thread-Specific Storage撰寫一個HibernateUtil

																import java.io.Serializable;

import net.sf.hibernate.HibernateException;
import net.sf.hibernate.Session;
import net.sf.hibernate.SessionFactory;
import net.sf.hibernate.Transaction;

public class HibernateSessionUtil implements Serializable
{
publicstaticfinal ThreadLocal tLocalsess = new ThreadLocal();

publicstaticfinal ThreadLocal tLocaltx = new ThreadLocal();

    /*
     * getting the thread-safe session for using
     */
publicstatic Session currentSession(){
        Session session = (Session) tLocalsess.get();

//open a new one, if none can be found.
try{
if (session == null){
                session = openSession();
                tLocalsess.set(session);
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
return session;
    }

    /*
     * closing the thread-safe session
     */
publicstatic void closeSession(){

        Session session = (Session) tLocalsess.get();
        tLocalsess.set(null);
try{
if (session != null && session.isOpen()){
                session.close();
            }

        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * begin the transaction
     */
publicstatic void beginTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
if (tx == null){
                tx = currentSession().beginTransaction();
                tLocaltx.set(tx);
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * close the transaction
     */
publicstatic void commitTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
if (tx != null && !tx.wasCommitted() && !tx.wasRolledBack())
                tx.commit();
            tLocaltx.set(null);
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * for rollbacking
     */
publicstatic void rollbackTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
            tLocaltx.set(null);
if (tx != null && !tx.wasCommitted() && !tx.wasRolledBack()){
                tx.rollback();
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

privatestatic Session openSession() throws HibernateException{
return getSessionFactory().openSession();
    }

privatestatic SessionFactory getSessionFactory() throws HibernateException{
return SingletonSessionFactory.getInstance();
    }
}

　filter中的程式碼如下

																public class HibernateSessionCloser implements Filter{

protected FilterConfig filterConfig = null;

public void init(FilterConfig filterConfig)throws ServletException{
this.filterConfig = filterConfig;
    }

public void destroy(){
this.filterConfig = null;
    }    

public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain)
throws IOException, ServletException {
try{
            chain.doFilter(request, response);
        }
finally{
try{
                HibernateSessionUtil.commitTransaction();
            }catch (InfrastructureException e){
                HibernateSessionUtil.rollbackTransaction();
            }finally{
                HibernateSessionUtil.closeSession();
            }   
        }

    }
}

然後在操作資料庫之前加上

HibernateSessionUtil.beginTransaction();
HibernateSessionUtil.currentSession();//取得Session

看看Hibernate Validator 是怎么做的吧.一见到她,相信你就会说: Oh God, 这就是我需要的.

任何获得Matrix授权的网站，转载请保留以下作者信息和链接：
作者：icess(作者的blog:http://blog.matrix.org.cn/page/icess)
关键字：Hibernate Validator

用Annotations 给类或者类的属性加上约束(constraint),在运行期检查属性值是很优雅的.Hibernate Validator就是这样的一个框架.该框架是十分容易的(就像参考文档中宣称的那样),几乎没有什么学习曲线,Validator 是一个验证框架 不需要和Hibernate的其他部分绑定就可以使用,只要在你的项目中添加Hibernate-annotations.jar库就可以了.那么下面就让我们看看怎么使用吧.

Person.java 类

/*
  * Created on 2006-1-12 Person.java
  * @author 
  */
package  test.annotation.validator;

import  org.hibernate.validator.Length;
import  org.hibernate.validator.Min;
import  org.hibernate.validator.Valid;
　

//@Serializability  //测试自定义约束
public class  Person {

   private  String name;
   private int  age;
   private  Address address;
  
   public  Person() {}
  
   @Valid //注意此处
   public  Address getAddress() {
     return  address;
   }
   public void  setAddress(Address address) {
     this .address = address;
   }
  
   @Min(value =  1 )
   public int  getAge() {
     return  age;
   }
   public void  setAge( int  age) {
     this .age = age;
   }
  
   @Length(min =  4 )
   public  String getName() {
     return  name;
   }
   public void  setName(String name) {
     this .name = name;
   }
}

Address.java 类

/*
  * Created on 2006-1-12 Address.java
  * @author 
  */
package  test.annotation.validator;

import  org.hibernate.validator.Length;
import  org.hibernate.validator.Max;
import  org.hibernate.validator.Min;

public class  Address {

   private  String street;
   private int  num;
  
   public  Address() {}
  
   @Min(value =  1 )
   @Max(value =  100 )
   public int  getNum() {
     return  num;
   }
   public void  setNum( int  num) {
     this .num = num;
   }
  
   @Length(min =  3 ,max =  8 )
   public  String getStreet() {
     return  street;
   }
   public void  setStreet(String street) {
     this .street = street;
   }
}

TestValidator.java 类

/*
  * Created on 2006-1-12
  * @author icerain
  */
package  test.annotation.validator;

import  org.hibernate.validator.ClassValidator;
import  org.hibernate.validator.InvalidValue;


public class  TestValidator {
   public void  test() {
     Address add =  new  Address();
     add.setNum( 0 );
     add.setStreet( "1" );
    
     Person p =  new  Person();
     p.setAddress(add);
     p.setAge( 0 );
     p.setName( "ice" );
    
     /******************Test validator ********/

    // 注意该处只验证了Person 为了说明 @Valid 注释的使用
     ClassValidator<Person> classValidator =  new  ClassValidator<Person> (Person. class );
     InvalidValue[] validMessages = classValidator.getInvalidValues(p);
     for  (InvalidValue value : validMessages) {
      
     System.out.println( "InvalidValue 的长度是:"  + validMessages.length
         + " . 验证消息是: "  + value.getMessage() 
         +  " . PropertyPath 是:"  + value.getPropertyPath()
         + " .\n\t PropertyName 是: "  +value.getPropertyName()
         +  "Value 是: "  + value.getValue()
         + " Bean 是: " + value.getBean()
         + "\n\t BeanClass 是:"  + value.getBeanClass());
     }
   }
  
   public static void  main(String[] args) {
     new  TestValidator().test();
   }
}

程序的输出如下

InvalidValue 的长度是:4 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@dd87b2

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:4 . 验证消息是: 长度必须介于 4 与 2147483647 之间 . PropertyPath 是:name .

PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@dd87b2

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:4 . 验证消息是: 必须大于等于 1 . PropertyPath 是:address.num .

PropertyName 是: num. Value 是: 0 Bean 是: test.annotation.validator.Address@197d257

BeanClass 是:class test.annotation.validator.Address

InvalidValue 的长度是:4 . 验证消息是: 长度必须介于 3 与 8 之间 . PropertyPath 是:address.street .

PropertyName 是: street. Value 是: 1 Bean 是: test.annotation.validator.Address@197d257

BeanClass 是:class test.annotation.validator.Address

可以看出不满足约束的值都被指出了.

同时该句: ClassValidator<Person> classValidator = new ClassValidator<Person> (Person.class);

我们只验证了 Person. 在Person里面的Address的属性 由于有@Valid Annotations 所以 Address的相关属性也被机联验证了 .

如果 把 @Valid Annotations 去掉,结果如下:

InvalidValue 的长度是:2 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@18fef3d

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:2 . 验证消息是: 长度必须介于 4 与 2147483647 之间 . PropertyPath 是:name .

PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@18fef3d

BeanClass 是:class test.annotation.validator.Person

可以看出 没有验证 Address.

当然了 ,你还可以只验证一个属性 , 没有必要验证整个类.只需要在调用 classValidator.getInvalidValues(p,"age")方法时 加上你要验证的属性就可以了.如我们只想验证age 属性 把代码改为如下所示:

InvalidValue[] validMessages = classValidator.getInvalidValues(p,"age"); / /只验证age 属性

运行结果如下:

InvalidValue 的长度是:1 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@1457cb

BeanClass 是:class test.annotation.validator.Person

只是验证了 age 属性.

怎么样 ,很简单吧. 关于 Hibernate Validator 内建的验证Annotations 大家可以看看 API 或者 参考文档(中文版我正在翻译中 请访问我的 Blog 获得最新信息).

如果你要写自己的约束呢 , 你不用担心 ,这也是很容易的. 任何约束有两部分组成: [约束描述符 即注释]the constraint descriptor (the annotation) 和[约束validator 即 实现类] the constraint validator (the implementation class).下面我们扩展Hibernate Test suit 中的一个Test 来讲解一下.

@ValidatorClass(SerializabilityValidator. class ) 指出了 constraint validator 类.

@Target({METHOD,FIELD,TYPE})
@Retention(RUNTIME)
@Documented                

这几个我就不用解释了吧.

Serializability 里面声明了一个 message 显示约束的提示信息. num 只是为了说明一个方面 在这里面没有实际用途用 .

然后就是 实现一个 constraint validator 类 该类要实现Validator<ConstraintAnnotation>.这里是SerializabilityValidator.java 如下:

//$Id: SerializabilityValidator.java,v 1.3 2005/11/17 18:12:11 epbernard Exp $
package  test.annotation.validator;

import  java.io.Serializable;

import  org.hibernate.validator.Validator;

/**
  * Sample of a bean-level validator
  *
  *  @author  Emmanuel Bernard
  */
public class  SerializabilityValidator  implements  Validator<Serializability>, Serializable {
   public boolean  isValid(Object value) {
    //这里只是Validator 里面的 实现验证规则的 方法. value 是要验证的值.
     System.out.println( "IN SerializabilityValidator isValid:" +value.getClass()+ ": "  +value.toString());
     return  value instanceof Serializable;
  }

  public void initialize(Serializability parameters) {
    // 在这里可以 取得 constraint descriptor 里面的属性 如上面我们声明的 num
     System.out.println( "IN SerializabilityValidator: parameters:" + parameters.num() );
   }
}

然后在你的类中应用@Serializability  就可以约束一个类实现Serializable 接口了. 如下:

在我们的Person.java类 添加@Serializability  Annotations ,把Person.java 中的 //@Serializability //测试自定义约束 注释去掉就ok了.

运行结果如下:

InvalidValue 的长度是:3 . 验证消息是: bean must be serialiable . PropertyPath 是:null .

现在把Person类实现 java.io.Serializable 接口 则没有出现 验证错误消息.

消息的国际化也是很简单的,把 Serializability  中的message 改为以{}扩住的 属性文件的Key就可以了

public  @interface Serializability {
   int  num()  default  11 ;
   String message()  default  "{Serializable}"; //"bean must be serialiable"; //消息的国际化
}

然后编辑资料文件. 注意 该资源文件中要包括 Hibernate Validator 内建的资源. 可以在该org\hibernate\validator\resources 包里面的资源文件基础上修改 ,在打包里面 这样就可以了. 自己打包可能不太方便.你可以把该包里面的文件复制出来.然后放到你自己的项目包下在自己编辑, 该测试中 我是放在 test\resources 包下的.

然后在 资源文件中添加 Serializable = '''''' 这么一行, 样例如下:

#DefaultValidatorMessages.properties (DefaultValidatorMessages_zh.properties 不再列出^_^)

#下面是 Hibernate Validator 内建的国际化消息

validator.assertFalse= assertion failed

validator.assertTrue= assertion failed

validator.future= must be a future date

validator.length= length must be between {min} and {max}

validator.max= must be less than or equal to {value}

validator.min= must be greater than or equal to {value}

validator.notNull= may not be null

validator.past= must be a past date

validator.pattern= must match "{regex}"

validator.range= must be between {min} and {max}

validator.size= size must be between {min} and {max}

#下面是自定义的消息

Serializable= Bean not Serializable  //加上自己定义的国际化消息.

在构造 ClassValidator 时要添上 资源文件 如下:(在测试类中)

ClassValidator<Person> classValidator = new ClassValidator<Person> (Person.class,ResourceBundle.getBundle("test.resources.DefaultValidatorMessages"));//加载资源

这样就可以了 .  当然 你还可以 更改 Hibernate Validator 的消息(不是在上面的资源文件中直接修改 validator.length = ... 等等 ) , 还记得 Validator 注释中有个 message 元素吗? 你以前用的都是默认值,现在你可以该为你自己定义的了. 如:validator.length 我把他改为 "该字符串的长度不符合规定范围范围". 在资源文件中添加一行键值属性对(key定义为 "myMsg")如下:

myMsg=该字符串的长度不符合规定范围范围

并且还要在 @Length 注释中提供message的引用的key 如下 @Length(min = 4,message = "{ myMsg }")

再一次运行测试 ,我们就可以看到上面两条自定义绑定的消息了 .如下:

InvalidValue 的长度是:3 . 验证消息是: Bean 不是 可 Serializable . PropertyPath 是:null .
PropertyName 是: null. Value 是: test.annotation.validator.Person@1bd4722 Bean 是: test.annotation.validator.Person@1bd4722
BeanClass 是:class test.annotation.validator.Person


InvalidValue 的长度是:3 . 验证消息是: 该字符串的长度不符合规定范围范围 . PropertyPath 是:name .
PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@1bd4722
BeanClass 是:class test.annotation.validator.Person

怎么样,比你想象的简单吧.

OK 上面我们讨论了 Hibernate Validator 的主要用法: 但是 该框架有什么用呢? ^_^

看到这里其实不用我在多说了 大家都知道怎么用,什么时候用. 作为一篇介绍性文章我还是在此给出一个最常用的例子吧,更好的使用方式大家慢慢挖掘吧.

比如 : 你现在在开发一个人力资源(HR)系统 (其实是我们ERP课程的一个作业 ^_^), 里面要处理大量的数据,尤其是在输入各种资料时 如 登记员工信息. 如果你公司的员工的年龄要求是18 -- 60 那么你所输入的年龄就不能超出这个范围. 你可能会说这很容易啊 , 不用Validator就可以解决啊.这保持数据前验证就可以啦 如if ( e.getAge() > 60 || e.getAge() < 18 ) ........ 给出错误信息 然后提示重新输入不就OK啦 用得着 兴师动众的来个第三方框架吗?

是啊 当就验证这一个属性时, 没有必要啊 ! 但是一个真正的HR 系统,会只有一个属性要验证吗? 恐怕要有N多吧

你要是每一个都那样 写一段验证代码 是不是很烦啊 ,况且也不方便代码重用. 现在考虑一些 Validator 是不是更高效啊,拦截到 约束违例的 属性 就可以直接得到 国际化的消息 可以把该消息显示到一个弹出对话框上 提示更正  !

Validator的用处不只这一种 ,你可以想到如何用呢 ! 欢迎发表你的高见!!

OK 到此 我们的 Hibernate Validator 之旅就要先告一段落了 . 希望这是令你心旷神怡的一次寒冬之旅,

把你学到的应用到你的项目中吧,一定会提高你的生产率的. 相信我 ,没错的  ^_^ !

对于大多数开发人员，为系统中的每个 DAO 编写几乎相同的代码到目前为止已经成为一种习惯。虽然所有人都将这种重复标识为 “代码味道”，但我们大多数都已经学会忍受它。其实有解决方案。可以使用许多 ORM 工具来避免代码重复。例如，使用 Hibernate，您可以简单地为所有的持久域对象直接使用会话操作。这种方法的缺点是损失了类型安全。

为什么您要为数据访问代码提供类型安全接口？我会争辩说，当它与现代 IDE 工具一起使用时，会减少编程错误并提高生产率。首先，类型安全接口清楚地指明哪些域对象具有可用的持久存储。其次，它消除了易出错的类型强制转换的需要（这是一个在查询操作中比在 CRUD 中更常见的问题）。最后，它有效利用了今天大多数 IDE 具备的自动完成特性。使用自动完成是记住什么查询可用于特定域类的快捷方法。

在本文中，我将为您展示如何避免再三地重复 DAO 代码，而仍保留类型安全接口的优点。事实上，您需要为每个新 DAO 编写的只是 Hibernate 映射文件、无格式旧 Java 接口以及 Spring 配置文件中的 10 行。

DAO 实现

DAO 模式对任何企业 Java 开发人员来说都应该很熟悉。但是模式的实现各不相同，所以我们来澄清一下本文提供的 DAO 实现背后的假设：

• 系统中的所有数据库访问都通过 DAO 进行以实现封装。
• 每个 DAO 实例负责一个主要域对象或实体。如果域对象具有独立生命周期，它应具有自己的 DAO。
• DAO 负责域对象的创建、读取（按主键）、更新和删除（creations, reads, updates, and deletions，CRUD）。
• DAO 可允许基于除主键之外的标准进行查询。我将之称为查找器方法 或查找器。查找器的返回值通常是 DAO 负责的域对象集合。
• DAO 不负责处理事务、会话或连接。这些不由 DAO 处理是为了实现灵活性。

泛型 DAO 接口

泛型 DAO 的基础是其 CRUD 操作。下面的接口定义泛型 DAO 的方法：

public interface GenericDao <T, PK extends Serializable> {

    /** Persist the newInstance object into database */
    PK create(T newInstance);

    /** Retrieve an object that was previously persisted to the database using
     *   the indicated id as primary key
     */
    T read(PK id);

    /** Save changes made to a persistent object.  */
    void update(T transientObject);

    /** Remove an object from persistent storage in the database */
    void delete(T persistentObject);
}

实现接口

用 Hibernate 实现清单 1 中的接口十分简单，如清单 2 所示。它只需调用底层 Hibernate 方法和添加强制类型转换。Spring 负责会话和事务管理。（当然，我假设这些函数已做了适当的设置，但该主题在 Hibernate 和 Springt 手册中有详细介绍。）

public class GenericDaoHibernateImpl <T, PK extends Serializable>
    implements GenericDao<T, PK>, FinderExecutor {
    private Class<T> type;

    public GenericDaoHibernateImpl(Class<T> type) {
        this.type = type;
    }

    public PK create(T o) {
        return (PK) getSession().save(o);
    }

    public T read(PK id) {
        return (T) getSession().get(type, id);
    }

    public void update(T o) {
        getSession().update(o);
    }

    public void delete(T o) {
        getSession().delete(o);
    }

    // Not showing implementations of getSession() and setSessionFactory()
            }

Spring 配置

最后，在 Spring 配置中，我创建了 GenericDaoHibernateImpl 的一个实例。必须告诉 GenericDaoHibernateImpl 的构造函数 DAO 实例将负责哪个域类。只有这样，Hibernate 才能在运行时知道由 DAO 管理的对象类型。在清单 3 中，我将域类 Person 从示例应用程序传递给构造函数，并将先前配置的 Hibernate 会话工厂设置为已实例化的 DAO 的参数：

<bean id="personDao" class="genericdao.impl.GenericDaoHibernateImpl">
        <constructor-arg>
            <value>genericdaotest.domain.Person</value>
        </constructor-arg>
        <property name="sessionFactory">
            <ref bean="sessionFactory"/>
        </property>
</bean>
        

可用的泛型 DAO

我还没有完成，但我所完成的确实已经可以使用了。在清单 4 中，可以看到原封不动使用该泛型 DAO 的示例：

public void someMethodCreatingAPerson() {
    ...
    GenericDao dao = (GenericDao)
     beanFactory.getBean("personDao"); // This should normally be injected

    Person p = new Person("Per", 90);
    dao.create(p);
}
        

现在，我有一个能够进行类型安全 CRUD 操作的泛型 DAO。让子类 GenericDaoHibernateImpl 为每个域对象添加查询能力将非常合理。因为本文的目的在于展示如何不为每个查询编写显式的 Java 代码来实现查询，但是，我将使用其他两个工具将查询引入 DAO，也就是 Spring AOP 和 Hibernate 命名的查询。

Spring AOP introductions

可以使用 Spring AOP 中的 introductions 将功能添加到现有对象，方法是将功能包装在代理中，定义应实现的接口，并将所有先前未支持的方法指派到单个处理程序。在我的 DAO 实现中，我使用 introductions 将许多查找器方法添加到现有泛型 DAO 类中。因为查找器方法是特定于每个域对象的，因此将其应用于泛型 DAO 的类型化接口。

Spring 配置如清单 5 所示：

<bean id="finderIntroductionAdvisor" class="genericdao.impl.FinderIntroductionAdvisor"/>

<bean id="abstractDaoTarget"
        class="genericdao.impl.GenericDaoHibernateImpl" abstract="true">
        <property name="sessionFactory">
            <ref bean="sessionFactory"/>
        </property>
</bean>

<bean id="abstractDao"
        class="org.springframework.aop.framework.ProxyFactoryBean" abstract="true">
        <property name="interceptorNames">
            <list>
                <value>finderIntroductionAdvisor</value>
            </list>
        </property>
</bean>
        

在清单 5 的配置文件中，我定义了三个 Spring bean。第一个 bean 是 FinderIntroductionAdvisor，它处理引入到 DAO 的所有方法，这些方法在 GenericDaoHibernateImpl 类中不可用。我稍后将详细介绍 Advisor bean。

第二个 bean 是 “抽象的”。在 Spring 中，这意味着该 bean 可在其他 bean 定义中被重用，但不被实例化。除了抽象特性之外，该 bean 定义只指出我想要 GenericDaoHibernateImpl 的实例以及该实例需要对 SessionFactory 的引用。注意，GenericDaoHibernateImpl 类仅定义一个构造函数，该构造函数接受域类作为其参数。因为该 bean 定义是抽象的，所以我将来可以无数次地重用该定义，并将构造函数参数设置为合适的域类。

最后，第三个也是最有趣的 bean 将 GenericDaoHibernateImpl 的 vanilla 实例包装在代理中，赋予其执行查找器方法的能力。该 bean 定义也是抽象的，不指定希望引入到 vanilla DAO 的接口。该接口对于每个具体的实例是不同的。注意，清单 5 显示的整个配置仅定义一次。

扩展 GenericDAO

当然，每个 DAO 的接口都基于 GenericDao 接口。我只需使该接口适应特定的域类并扩展该接口以包括查找器方法。在清单 6 中，可以看到为特定目的扩展的 GenericDao 接口示例：

public interface PersonDao extends GenericDao<Person, Long> {
    List<Person> findByName(String name);
}

很明显，清单 6 中定义的方法旨在按名称查找 Person。必需的 Java 实现代码全部是泛型代码，在添加更多 DAO 时不需要任何更新。

配置 PersonDao

因为 Spring 配置依赖于先前定义的 “抽象” bean，因此它变得相当简洁。我需要指出 DAO 负责哪个域类，并且需要告诉 Springs 该 DAO 应实现哪个接口（一些方法是直接使用，一些方法则是通过使用 introductions 来使用）。清单 7 展示了 PersonDAO 的 Spring 配置文件：

<bean id="personDao" parent="abstractDao">
    <property name="proxyInterfaces">
        <value>genericdaotest.dao.PersonDao</value>
    </property>
    <property name="target">
        <bean parent="abstractDaoTarget">
            <constructor-arg>
                <value>genericdaotest.domain.Person</value>
            </constructor-arg>
        </bean>
    </property>
</bean>
        

在清单 8 中，可以看到使用了这个更新后的 DAO 版本：

public void someMethodCreatingAPerson() {
    ...
    PersonDao dao = (PersonDao)
     beanFactory.getBean("personDao"); // This should normally be injected

    Person p = new Person("Per", 90);
    dao.create(p);

    List<Person> result = dao.findByName("Per"); // Runtime exception
}
        

虽然清单 8 中的代码是使用类型安全 PersonDao 接口的正确方法，但 DAO 的实现并不完整。调用 findByName() 会导致运行时异常。问题在于我还没有实现调用 findByName() 所必需的查询。剩下要做的就是指定查询。为更正该问题，我使用了 Hibernate 命名查询。

Hibernate 命名查询

使用 Hibernate，可以在 Hibernate 映射文件 (hbm.xml) 中定义 HQL 查询并为其命名。稍后可以通过简单地引用给定名称来在 Java 代码中使用该查询。该方法的优点之一是能够在部署时优化查询，而无需更改代码。您一会将会看到，另一个优点是无需编写任何新 Java 实现代码，就可以实现 “完整的” DAO。清单 9 是带有命名查询的映射文件的示例：

 <hibernate-mapping package="genericdaotest.domain">
     <class name="Person">
         <id name="id">
             <generator class="native"/>
         </id>
         <property name="name" />
         <property name="weight" />
     </class>

     <query name="Person.findByName">
         <![CDATA[select p from Person p where p.name = ? ]]>
     </query>
 </hibernate-mapping>
        

清单 9 定义了域类 Person 的 Hibernate 映射，该域类具有两个属性：name 和 weight。Person 是具有上述属性的简单 POJO。该文件还包含一个在数据库中查找 Person 所有实例的查询，其中 “name” 等于提供的参数。Hibernate 不为命名查询提供任何真正的名称空间功能。出于讨论目的，我为所有查询名称都加了域类的短（非限定）名称作为前缀。在现实世界中，使用包括包名称的完全类名可能是更好的主意。

逐步概述

您已经看到了为任何域对象创建和配置新 DAO 所必需的全部步骤。三个简单的步骤是：

1. 定义一个接口，它扩展 GenericDao 并包含所需的任何查找器方法。
2. 将每个查找器的命名查询添加到域对象的 hbm.xml 映射文件。
3. 为 DAO 添加 10 行 Spring 配置文件。

查看执行查找器方法的代码（只编写了一次！）来结束我的讨论。

可重用的 DAO 类

使用的 Spring advisor 和 interceptor 很简单，事实上它们的工作是向后引用 GenericDaoHibernateImplClass。方法名以 “find” 打头的所有调用都传递给 DAO 和单个方法 executeFinder()。

public class FinderIntroductionAdvisor extends DefaultIntroductionAdvisor {
    public FinderIntroductionAdvisor() {
        super(new FinderIntroductionInterceptor());
    }
}

public class FinderIntroductionInterceptor implements IntroductionInterceptor {

    public Object invoke(MethodInvocation methodInvocation) throws Throwable {

        FinderExecutor genericDao = (FinderExecutor) methodInvocation.getThis();

        String methodName = methodInvocation.getMethod().getName();
        if (methodName.startsWith("find")) {
            Object[] arguments = methodInvocation.getArguments();
            return genericDao.executeFinder(methodInvocation.getMethod(), arguments);
        } else {
            return methodInvocation.proceed();
        }
    }

    public boolean implementsInterface(Class intf) {
        return intf.isInterface() && FinderExecutor.class.isAssignableFrom(intf);
    }
}

executeFinder() 方法

清单 10 的实现中惟一缺少的是 executeFinder() 实现。该代码查看调用的类和方法的名称，并使用配置上的约定将其与 Hibernate 查询的名称相匹配。还可以使用 FinderNamingStrategy 来支持其他命名查询的方法。默认实现查找叫做 “ClassName.methodName” 的查询，其中 ClassName 是不带包的短名称。清单 11 完成了泛型类型安全 DAO 实现：

public List<T> executeFinder(Method method, final Object[] queryArgs) {
     final String queryName = queryNameFromMethod(method);
     final Query namedQuery = getSession().getNamedQuery(queryName);
     String[] namedParameters = namedQuery.getNamedParameters();
     for(int i = 0; i < queryArgs.length; i++) {
             Object arg = queryArgs[i];
             Type argType =  namedQuery.setParameter(i, arg);
      }
      return (List<T>) namedQuery.list();
 }

 public String queryNameFromMethod(Method finderMethod) {
     return type.getSimpleName() + "." + finderMethod.getName();
 }

结束语

在 Java 5 之前，该语言不支持编写既类型安全又 泛型的代码，您必须只能选择其中之一。在本文中，您已经看到一个结合使用 Java 5 泛型与 Spring 和 Hibernate（以及 AOP）等工具来提高生产率的示例。泛型类型安全 DAO 类相当容易编写 —— 您只需要单个接口、一些命名查询和为 Spring 配置添加的 10 行代码 —— 而且可以极大地减少错误并节省时间。

几乎本文的所有代码都是可重用的。尽管您的 DAO 类可能包含此处没有实现的查询和操作类型（比如，批操作），但使用我所展示的技术，您至少应该能够实现其中的一部分。参阅 参考资料 了解其他泛型类型安全 DAO 类实现。

致谢

自 Java 语言中出现泛型以来，单个泛型类型安全 DAO 的概念已经成为主题。我曾在 JavaOne 2004 中与 Don Smith 简要讨论了泛型 DAO 的灵活性。本文使用的 DAO 实现类旨在作为示例实现，实际上还存在其他实现。例如，Christian Bauer 已经发布了带有 CRUD 操作和标准搜索的实现，Eric Burke 也在该领域做出了工作。我确信将会有更多的实现出现。我要额外感谢 Christian，他目睹了我编写泛型类型安全 DAO 的第一次尝试并提出改进建议。最后，我要感谢 Ramnivas Laddad 的无价帮助，他审阅了本文。

对于大多数开发人员，为系统中的每个 DAO 编写几乎相同的代码到目前为止已经成为一种习惯。虽然所有人都将这种重复标识为 “代码味道”，但我们大多数都已经学会忍受它。其实有解决方案。可以使用许多 ORM 工具来避免代码重复。例如，使用 Hibernate，您可以简单地为所有的持久域对象直接使用会话操作。这种方法的缺点是损失了类型安全。

为什么您要为数据访问代码提供类型安全接口？我会争辩说，当它与现代 IDE 工具一起使用时，会减少编程错误并提高生产率。首先，类型安全接口清楚地指明哪些域对象具有可用的持久存储。其次，它消除了易出错的类型强制转换的需要（这是一个在查询操作中比在 CRUD 中更常见的问题）。最后，它有效利用了今天大多数 IDE 具备的自动完成特性。使用自动完成是记住什么查询可用于特定域类的快捷方法。

在本文中，我将为您展示如何避免再三地重复 DAO 代码，而仍保留类型安全接口的优点。事实上，您需要为每个新 DAO 编写的只是 Hibernate 映射文件、无格式旧 Java 接口以及 Spring 配置文件中的 10 行。

DAO 实现

DAO 模式对任何企业 Java 开发人员来说都应该很熟悉。但是模式的实现各不相同，所以我们来澄清一下本文提供的 DAO 实现背后的假设：

• 系统中的所有数据库访问都通过 DAO 进行以实现封装。
• 每个 DAO 实例负责一个主要域对象或实体。如果域对象具有独立生命周期，它应具有自己的 DAO。
• DAO 负责域对象的创建、读取（按主键）、更新和删除（creations, reads, updates, and deletions，CRUD）。
• DAO 可允许基于除主键之外的标准进行查询。我将之称为查找器方法 或查找器。查找器的返回值通常是 DAO 负责的域对象集合。
• DAO 不负责处理事务、会话或连接。这些不由 DAO 处理是为了实现灵活性。

泛型 DAO 接口

泛型 DAO 的基础是其 CRUD 操作。下面的接口定义泛型 DAO 的方法：

public interface GenericDao <T, PK extends Serializable> {

    /** Persist the newInstance object into database */
    PK create(T newInstance);

    /** Retrieve an object that was previously persisted to the database using
     *   the indicated id as primary key
     */
    T read(PK id);

    /** Save changes made to a persistent object.  */
    void update(T transientObject);

    /** Remove an object from persistent storage in the database */
    void delete(T persistentObject);
}

实现接口

用 Hibernate 实现清单 1 中的接口十分简单，如清单 2 所示。它只需调用底层 Hibernate 方法和添加强制类型转换。Spring 负责会话和事务管理。（当然，我假设这些函数已做了适当的设置，但该主题在 Hibernate 和 Springt 手册中有详细介绍。）

public class GenericDaoHibernateImpl <T, PK extends Serializable>
    implements GenericDao<T, PK>, FinderExecutor {
    private Class<T> type;

    public GenericDaoHibernateImpl(Class<T> type) {
        this.type = type;
    }

    public PK create(T o) {
        return (PK) getSession().save(o);
    }

    public T read(PK id) {
        return (T) getSession().get(type, id);
    }

    public void update(T o) {
        getSession().update(o);
    }

    public void delete(T o) {
        getSession().delete(o);
    }

    // Not showing implementations of getSession() and setSessionFactory()
            }

Spring 配置

最后，在 Spring 配置中，我创建了 GenericDaoHibernateImpl 的一个实例。必须告诉 GenericDaoHibernateImpl 的构造函数 DAO 实例将负责哪个域类。只有这样，Hibernate 才能在运行时知道由 DAO 管理的对象类型。在清单 3 中，我将域类 Person 从示例应用程序传递给构造函数，并将先前配置的 Hibernate 会话工厂设置为已实例化的 DAO 的参数：

<bean id="personDao" class="genericdao.impl.GenericDaoHibernateImpl">
        <constructor-arg>
            <value>genericdaotest.domain.Person</value>
        </constructor-arg>
        <property name="sessionFactory">
            <ref bean="sessionFactory"/>
        </property>
</bean>

可用的泛型 DAO

我还没有完成，但我所完成的确实已经可以使用了。在清单 4 中，可以看到原封不动使用该泛型 DAO 的示例：

public void someMethodCreatingAPerson() {
    ...
    GenericDao dao = (GenericDao)
     beanFactory.getBean("personDao"); // This should normally be injected

    Person p = new Person("Per", 90);
    dao.create(p);
}

现在，我有一个能够进行类型安全 CRUD 操作的泛型 DAO。让子类 GenericDaoHibernateImpl 为每个域对象添加查询能力将非常合理。因为本文的目的在于展示如何不为每个查询编写显式的 Java 代码来实现查询，但是，我将使用其他两个工具将查询引入 DAO，也就是 Spring AOP 和 Hibernate 命名的查询。

Spring AOP introductions

可以使用 Spring AOP 中的 introductions 将功能添加到现有对象，方法是将功能包装在代理中，定义应实现的接口，并将所有先前未支持的方法指派到单个处理程序。在我的 DAO 实现中，我使用 introductions 将许多查找器方法添加到现有泛型 DAO 类中。因为查找器方法是特定于每个域对象的，因此将其应用于泛型 DAO 的类型化接口。

Spring 配置如清单 5 所示：

<bean id="finderIntroductionAdvisor" class="genericdao.impl.FinderIntroductionAdvisor"/>

<bean id="abstractDaoTarget"
        class="genericdao.impl.GenericDaoHibernateImpl" abstract="true">
        <property name="sessionFactory">
            <ref bean="sessionFactory"/>
        </property>
</bean>

<bean id="abstractDao"
        class="org.springframework.aop.framework.ProxyFactoryBean" abstract="true">
        <property name="interceptorNames">
            <list>
                <value>finderIntroductionAdvisor</value>
            </list>
        </property>
</bean>

在清单 5 的配置文件中，我定义了三个 Spring bean。第一个 bean 是 FinderIntroductionAdvisor，它处理引入到 DAO 的所有方法，这些方法在 GenericDaoHibernateImpl 类中不可用。我稍后将详细介绍 Advisor bean。

第二个 bean 是 “抽象的”。在 Spring 中，这意味着该 bean 可在其他 bean 定义中被重用，但不被实例化。除了抽象特性之外，该 bean 定义只指出我想要 GenericDaoHibernateImpl 的实例以及该实例需要对 SessionFactory 的引用。注意，GenericDaoHibernateImpl 类仅定义一个构造函数，该构造函数接受域类作为其参数。因为该 bean 定义是抽象的，所以我将来可以无数次地重用该定义，并将构造函数参数设置为合适的域类。

最后，第三个也是最有趣的 bean 将 GenericDaoHibernateImpl 的 vanilla 实例包装在代理中，赋予其执行查找器方法的能力。该 bean 定义也是抽象的，不指定希望引入到 vanilla DAO 的接口。该接口对于每个具体的实例是不同的。注意，清单 5 显示的整个配置仅定义一次。

扩展 GenericDAO

当然，每个 DAO 的接口都基于 GenericDao 接口。我只需使该接口适应特定的域类并扩展该接口以包括查找器方法。在清单 6 中，可以看到为特定目的扩展的 GenericDao 接口示例：

public interface PersonDao extends GenericDao<Person, Long> {
    List<Person> findByName(String name);
}

很明显，清单 6 中定义的方法旨在按名称查找 Person。必需的 Java 实现代码全部是泛型代码，在添加更多 DAO 时不需要任何更新。

配置 PersonDao

因为 Spring 配置依赖于先前定义的 “抽象” bean，因此它变得相当简洁。我需要指出 DAO 负责哪个域类，并且需要告诉 Springs 该 DAO 应实现哪个接口（一些方法是直接使用，一些方法则是通过使用 introductions 来使用）。清单 7 展示了 PersonDAO 的 Spring 配置文件：

<bean id="personDao" parent="abstractDao">
    <property name="proxyInterfaces">
        <value>genericdaotest.dao.PersonDao</value>
    </property>
    <property name="target">
        <bean parent="abstractDaoTarget">
            <constructor-arg>
                <value>genericdaotest.domain.Person</value>
            </constructor-arg>
        </bean>
    </property>
</bean>

在清单 8 中，可以看到使用了这个更新后的 DAO 版本：

public void someMethodCreatingAPerson() {
    ...
    PersonDao dao = (PersonDao)
     beanFactory.getBean("personDao"); // This should normally be injected

    Person p = new Person("Per", 90);
    dao.create(p);

    List<Person> result = dao.findByName("Per"); // Runtime exception
}

虽然清单 8 中的代码是使用类型安全 PersonDao 接口的正确方法，但 DAO 的实现并不完整。调用 findByName() 会导致运行时异常。问题在于我还没有实现调用 findByName() 所必需的查询。剩下要做的就是指定查询。为更正该问题，我使用了 Hibernate 命名查询。

Hibernate 命名查询

使用 Hibernate，可以在 Hibernate 映射文件 (hbm.xml) 中定义 HQL 查询并为其命名。稍后可以通过简单地引用给定名称来在 Java 代码中使用该查询。该方法的优点之一是能够在部署时优化查询，而无需更改代码。您一会将会看到，另一个优点是无需编写任何新 Java 实现代码，就可以实现 “完整的” DAO。清单 9 是带有命名查询的映射文件的示例：

 <hibernate-mapping package="genericdaotest.domain">
     <class name="Person">
         <id name="id">
             <generator class="native"/>
         </id>
         <property name="name" />
         <property name="weight" />
     </class>

     <query name="Person.findByName">
         <![CDATA[select p from Person p where p.name = ? ]]>
     </query>
 </hibernate-mapping>

清单 9 定义了域类 Person 的 Hibernate 映射，该域类具有两个属性：name 和 weight。Person 是具有上述属性的简单 POJO。该文件还包含一个在数据库中查找 Person 所有实例的查询，其中 “name” 等于提供的参数。Hibernate 不为命名查询提供任何真正的名称空间功能。出于讨论目的，我为所有查询名称都加了域类的短（非限定）名称作为前缀。在现实世界中，使用包括包名称的完全类名可能是更好的主意。

逐步概述

您已经看到了为任何域对象创建和配置新 DAO 所必需的全部步骤。三个简单的步骤是：

1. 定义一个接口，它扩展 GenericDao 并包含所需的任何查找器方法。
2. 将每个查找器的命名查询添加到域对象的 hbm.xml 映射文件。
3. 为 DAO 添加 10 行 Spring 配置文件。

查看执行查找器方法的代码（只编写了一次！）来结束我的讨论。

可重用的 DAO 类

使用的 Spring advisor 和 interceptor 很简单，事实上它们的工作是向后引用 GenericDaoHibernateImplClass。方法名以 “find” 打头的所有调用都传递给 DAO 和单个方法 executeFinder()。

public class FinderIntroductionAdvisor extends DefaultIntroductionAdvisor {
    public FinderIntroductionAdvisor() {
        super(new FinderIntroductionInterceptor());
    }
}

public class FinderIntroductionInterceptor implements IntroductionInterceptor {

    public Object invoke(MethodInvocation methodInvocation) throws Throwable {

        FinderExecutor genericDao = (FinderExecutor) methodInvocation.getThis();

        String methodName = methodInvocation.getMethod().getName();
        if (methodName.startsWith("find")) {
            Object[] arguments = methodInvocation.getArguments();
            return genericDao.executeFinder(methodInvocation.getMethod(), arguments);
        } else {
            return methodInvocation.proceed();
        }
    }

    public boolean implementsInterface(Class intf) {
        return intf.isInterface() && FinderExecutor.class.isAssignableFrom(intf);
    }
}

executeFinder() 方法

清单 10 的实现中惟一缺少的是 executeFinder() 实现。该代码查看调用的类和方法的名称，并使用配置上的约定将其与 Hibernate 查询的名称相匹配。还可以使用 FinderNamingStrategy 来支持其他命名查询的方法。默认实现查找叫做 “ClassName.methodName” 的查询，其中 ClassName 是不带包的短名称。清单 11 完成了泛型类型安全 DAO 实现：

public List<T> executeFinder(Method method, final Object[] queryArgs) {
     final String queryName = queryNameFromMethod(method);
     final Query namedQuery = getSession().getNamedQuery(queryName);
     String[] namedParameters = namedQuery.getNamedParameters();
     for(int i = 0; i < queryArgs.length; i++) {
             Object arg = queryArgs[i];
             Type argType =  namedQuery.setParameter(i, arg);
      }
      return (List<T>) namedQuery.list();
 }

 public String queryNameFromMethod(Method finderMethod) {
     return type.getSimpleName() + "." + finderMethod.getName();
 }

结束语

在 Java 5 之前，该语言不支持编写既类型安全又 泛型的代码，您必须只能选择其中之一。在本文中，您已经看到一个结合使用 Java 5 泛型与 Spring 和 Hibernate（以及 AOP）等工具来提高生产率的示例。泛型类型安全 DAO 类相当容易编写 —— 您只需要单个接口、一些命名查询和为 Spring 配置添加的 10 行代码 —— 而且可以极大地减少错误并节省时间。

几乎本文的所有代码都是可重用的。尽管您的 DAO 类可能包含此处没有实现的查询和操作类型（比如，批操作），但使用我所展示的技术，您至少应该能够实现其中的一部分。参阅 参考资料 了解其他泛型类型安全 DAO 类实现。

致谢

自 Java 语言中出现泛型以来，单个泛型类型安全 DAO 的概念已经成为主题。我曾在 JavaOne 2004 中与 Don Smith 简要讨论了泛型 DAO 的灵活性。本文使用的 DAO 实现类旨在作为示例实现，实际上还存在其他实现。例如，Christian Bauer 已经发布了带有 CRUD 操作和标准搜索的实现，Eric Burke 也在该领域做出了工作。我确信将会有更多的实现出现。我要额外感谢 Christian，他目睹了我编写泛型类型安全 DAO 的第一次尝试并提出改进建议。最后，我要感谢 Ramnivas Laddad 的无价帮助，他审阅了本文。

　　 缓存的介质一般是内存，所以读写速度很快。但如果缓存中存放的数据量非常大时，也会用硬盘作为缓存介质。缓存的实现不仅仅要考虑存储的介质，还要考虑到管理缓存的并发访问和缓存数据的生命周期。

　　Hibernate 的缓存包括 Session 的缓存和 SessionFactory 的缓存，其中 SessionFactory 的缓存又可以分为两类：内置缓存和外置缓存。 Session 的缓存是内置的，不能被卸载，也被称为 Hibernate 的第一级缓存。 SessionFactory 的内置缓存和 Session 的缓存在实现方式上比较相似，前者是 SessionFactory 对象的一些集合属性包含的数据，后者是指 Session 的一些集合属性包含的数据。 SessionFactory 的内置缓存中存放了映射元数据和预定义 SQL 语句，映射元数据是映射文件中数据的拷贝，而预定义 SQL 语句是在 Hibernate 初始化阶段根据映射元数据推导出来， SessionFactory 的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义 SQL 语句，因此 SessionFactory 不需要进行内置缓存与映射文件的同步。 SessionFactory 的外置缓存是一个可配置的插件。在默认情况下， SessionFactory 不会启用这个插件。外置缓存的数据是数据库数据的拷贝，外置缓存的介质可以是内存或者硬盘。 SessionFactory 的外置缓存也被称为 Hibernate 的第二级缓存。

　　Hibernate 的这两级缓存都位于持久化层，存放的都是数据库数据的拷贝，那么它们之间的区别是什么呢？为了理解二者的区别，需要深入理解持久化层的缓存的两个特性：缓存的范围和缓存的并发访问策略。

持久化层的缓存的范围

　　 缓存的范围决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。

　　1 事务范围：缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期，当事务结束时，缓存也就结束生命周期。在此范围下，缓存的介质是内存。事务可以是数据库事务或者应用事务，每个事务都有独自的缓存，缓存内的数据通常采用相互关联的的对象形式。

　　2 进程范围：缓存被进程内的所有事务共享。这些事务有可能是并发访问缓存，因此必须对缓存采取必要的事务隔离机制。缓存的生命周期依赖于进程的生命周期，进程结束时，缓存也就结束了生命周期。进程范围的缓存可能会存放大量的数据，所以存放的介质可以是内存或硬盘。缓存内的数据既可以是相互关联的对象形式也可以是对象的松散数据形式。松散的对象数据形式有点类似于对象的序列化数据，但是对象分解为松散的算法比对象序列化的算法要求更快。

　　3 集群范围：在集群环境中，缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点，进程间通过远程通信来保证缓存中的数据的一致性，缓存中的数据通常采用对象的松散数据形式。

　　 对大多数应用来说，应该慎重地考虑是否需要使用集群范围的缓存，因为访问的速度不一定会比直接访问数据库数据的速度快多少。

　　 持久化层可以提供多种范围的缓存。如果在事务范围的缓存中没有查到相应的数据，还可以到进程范围或集群范围的缓存内查询，如果还是没有查到，那么只有到数据库中查询。事务范围的缓存是持久化层的第一级缓存，通常它是必需的；进程范围或集群范围的缓存是持久化层的第二级缓存，通常是可选的。

持久化层的缓存的并发访问策略

　　 当多个并发的事务同时访问持久化层的缓存的相同数据时，会引起并发问题，必须采用必要的事务隔离措施。

　　 在进程范围或集群范围的缓存，即第二级缓存，会出现并发问题。因此可以设定以下四种类型的并发访问策略，每一种策略对应一种事务隔离级别。

　　 事务型：仅仅在受管理环境中适用。它提供了 Repeatable Read 事务隔离级别。对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读和不可重复读这类的并发问题。

　　 读写型：提供了 Read Committed 事务隔离级别。仅仅在非集群的环境中适用。对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读这类的并发问题。

　　 非严格读写型：不保证缓存与数据库中数据的一致性。如果存在两个事务同时访问缓存中相同数据的可能，必须为该数据配置一个很短的数据过期时间，从而尽量避免脏读。对于极少被修改，并且允许偶尔脏读的数据，可以采用这种并发访问策略。

　　 只读型：对于从来不会修改的数据，如参考数据，可以使用这种并发访问策略。

　　 事务型并发访问策略是事务隔离级别最高，只读型的隔离级别最低。事务隔离级别越高，并发性能就越低。

什么样的数据适合存放到第二级缓存中？

1 很少被修改的数据

2 不是很重要的数据，允许出现偶尔并发的数据

3 不会被并发访问的数据

4 参考数据

不适合存放到第二级缓存的数据？

1 经常被修改的数据

2 财务数据，绝对不允许出现并发

3 与其他应用共享的数据。

Hibernate 的二级缓存

　　 如前所述， Hibernate 提供了两级缓存，第一级是 Session 的缓存。由于 Session 对象的生命周期通常对应一个数据库事务或者一个应用事务，因此它的缓存是事务范围的缓存。第一级缓存是必需的，不允许而且事实上也无法比卸除。在第一级缓存中，持久化类的每个实例都具有唯一的 OID 。

　　 第二级缓存是一个可插拔的的缓存插件，它是由 SessionFactory 负责管理。由于 SessionFactory 对象的生命周期和应用程序的整个过程对应，因此第二级缓存是进程范围或者集群范围的缓存。这个缓存中存放的对象的松散数据。第二级对象有可能出现并发问题，因此需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别。缓存适配器用于把具体的缓存实现软件与 Hibernate 集成。第二级缓存是可选的，可以在每个类或每个集合的粒度上配置第二级缓存。

Hibernate 的二级缓存策略的一般过程如下：

1) 条件查询的时候，总是发出一条 select * from table_name where …. （选择所有字段）这样的 SQL 语句查询数据库，一次获得所有的数据对象。

2) 把获得的所有数据对象根据 ID 放入到第二级缓存中。

3) 当 Hibernate 根据 ID 访问数据对象的时候，首先从 Session 一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照 ID 放入到缓存。

4) 删除、更新、增加数据的时候，同时更新缓存。

　　Hibernate 的二级缓存策略，是针对于 ID 查询的缓存策略，对于条件查询则毫无作用。为此， Hibernate 提供了针对条件查询的 Query 缓存。

Hibernate 的 Query 缓存策略的过程如下：

1) Hibernate 首先根据这些信息组成一个 Query Key ， Query Key 包括条件查询的请求一般信息： SQL, SQL 需要的参数，记录范围（起始位置 rowStart ，最大记录个数 maxRows) ，等。

2) Hibernate 根据这个 Query Key 到 Query 缓存中查找对应的结果列表。如果存在，那么返回这个结果列表；如果不存在，查询数据库，获取结果列表，把整个结果列表根据 Query Key 放入到 Query 缓存中。

3) Query Key 中的 SQL 涉及到一些表名，如果这些表的任何数据发生修改、删除、增加等操作，这些相关的 Query Key 都要从缓存中清空。