1. Lifecycle与Validatable
在某些情况下，我们需要对实体对象的CRUD操作进行捕获并执行相应的处理。在数据库层，这通常通过触发器（Triger）实现。
Hibernate 通过Lifecycle、Validatable接口制定了实体对象CRUD过程中的回调（CallBack）方式。
Lifecycle.java
public interface Lifecycle {
/**在实体对象Save/Insert操作之前触发*/
public boolean onSave(Session s) throws CallbackException;
/**在Session.update()操作之前触发*/
public boolean onUpdate(Session s)throws CallbackException;
/**在实体对象Delete操作之前触发*/
public boolean onDelete(Session s)throws CallbackException;
/**在实体对象被加载之后触发*/
public void onLoad(Session s, Serializable id);
}实体类通过实现Lifecycle接口，即可在特定的持久化阶段，触发特定的处理过程：
pulic class TUser implements Serializable,Lifecycle {
…
public boolean onSave(Session s)throws CallbackException {
…
return false;//insert操作正常执行
…
}
public boolean onUpdate(Session s)throws CallbackException{
…
if(…)return true;//update操作将被终止
}
public boolean onDelete(Session s)throws CallbackException{
…
return false;//delete操作正常执行
}
public void onLoad(Session s, Serialiable id){
…
}
}对于onSave、onUpdate、onDelete方法，如果返回true则意味着需要中止执行对应的操作过程。如果代码运行期间抛出了CallbackException，对应的操作也会被中止。
注：不要试图在这些方法中调用Session进行持久化操作，这些方法中Session无法正常使用。如果必须进行持久化操作，需要进行一些特殊处理，具体参见稍后关于Interceptor。
Validatable.java
public interface Validatable{
public void validate() throws ValidationFailure;
}Validatable接口定义了数据验证实现方式。实体类实现Validatable接口，并在validate对当前待保存的数据进行验证，以保证数据逻辑合法。
Validatable.validate方法将在实体被持久化之前得到调用以对数据进行验证。但注意，与Lifecycle的回调方法不同，此方法在实体对象的生命周期内可能被数次调用，因此，此方法应仅用于数据本身的逻辑校验，而不要试图在此实现业务逻辑的验证。
Lifecycle/Validatable接口定义了一种自然的回调机制。但是，这种机制要求实体类必须实现Lifecycle/Validatable接口，Hibernate原生接口的介入，使得我们的实体类移植性大大降低（实际上，此时的实体类已经不再是一个严格意义上的POJO）。
由于注意到这点，Hibernate引入了Interceptor，为持久化事件的捕获和处理提供了一个非侵略性的实现。
Interceptor
Interceptor接口定义了Hibernate中的通用拦截机制。Session创建时即可以指定加载相应的Interceptor，之后，此Session的持久化操作工作都将首先经由此拦截器捕获处理。
Interceptor.java
public interface Interceptor{
//对象初始化之前加载，这里的entity处于刚被创建的状态（也就是说属性均未赋值）
public boolean onLoad(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) throws CallbackException;
//Session.flush方法进行脏数据检查时，如果发现PO状态改变，则调用此方法
public boolean onFlushDirty(Object entity, Serializable id, Object[] currentState, Object[] previousState, String[] propertyNames, Type[] types) throws CallbackException;
//将在对象被保存之前调用，这提供了一个对待保存对象属性进行修改的机会
public boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) throws CallbackException;
//将在对象被删除之前调用
public boolean onDelete(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) throws CallbackException;
//Session执行flush方法之前被调用
public void preFlush(Iterator entities) throws CallbackException;
//Session执行flush方法之后被调用
public void postFlush(Iterator entities) throws CallbackException;
//Session.saveOrUpdate方法时，将调用此方法判断对象是否尚未保存
public Boolean isUnsaved(Object entity);
//Session.flush方法时，将调用此方法判断对象是否为脏数据，这提供了脏数据检查的另一个拦截式实现渠道
public int[] findDirty(Object entity, Serializable id, Object[] currentState, Object[] previousState, String[] propertyNames, Type[] types);
//用于创建实体对象时，如果返回null，则Hibernate将调用实体类的默认构造方法创建实体对象
public Object instantiate(Class clazz, Serializable id) throws CallbackException;
}另外值得注意的是，与Lifecycle相同，Interceptor的方法中不可通过Session实例进行持久化操作。关于Interceptor中的持久化实现参见“Interceptor典型应用”中的内容。
在创建Session实例时，我们可以通过编码加载Interceptor:
SessionFactory sessionFactory = cofig.buildSessionFactory(); Interceptor it = new MyInterceptor(); session = sessionFactory.openSession(it);
此后，此Session的所有动作均会被此Interceptor捕获。
假设MyInterceptor的实现如下：
public class MyInterceptor implements Interceptor{
…
public boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) throws CallbackException{
if(entity instanceof TUser){
System.out.println(“User to be saved=>”+((TUser)entity).getName());
}
return false;
}
…
}执行：
SessionFactory sessionFactory = cofig.buildSessionFactory(); Interceptor it = new MyInterceptor(); session = sessionFactory.openSession(it); TUser user = new TUser(); user.setName(“Erica”); Transaction tx= session.beginTransaction(); session.save(user); tx.commit(); session.close();
观察屏幕日志：
可以看到，MyInterceptor.onSave方法在Hibernate执行库表insert操作之前调用。
通过这个例子可以发现，Interceptor实际上覆盖了Lifecycle接口的功能，且具备更少的侵入性（实体类无需与任何Hibernate原生接口绑定）。
Interceptor典型应用
“数据稽核”功能是不少关键系统的必备功能。
何谓“数据稽核”？即针对关键信息及其变更历史进行审查，作为业务跟踪的基础依据。
那么如何实现关键信息更新操作的记录。显然这并不是个非常困难的技术问题。最常见的方式就是在各个业务逻辑单元中通过编码进行记录。
回顾上面关于Interceptor的探讨，我们可以发现，对于基于Hibernate的应用而言，通过Interceptor实现数据稽核功能也许是最自然的一种方式。
以t_user表操作为例，我们来看看基于Interceptor的实现方式。
Interceptor接口中，与数据更新操作相关的拦截方法有onSave和onFlushDirty。其中onSave方法对应insert操作，onFlushDirty对应update操作。
那么，我们只要针对这两个操作实现对应的拦截器方法，并在此方法中对更新历史进行保存，那么所有关于t_user表的修改操作都将被记录在案。
这种实现方式通过集中化的记录机制，避免了各业务逻辑单元中通过编码进行操作记录的可能缺漏，提供了最为全面的数据跟踪机制。另一方面，也避免了稽核逻辑在业务逻辑中分散，最大程度上避免了重复代码的出现。
假设“历史记录”实体机构如下：
public class TAuditLog implements Serializable{
private Integer id;
private String user;
private String action;
private String entityName;
private String comment;
private Long logtime;
…
}对应的Interceptor实现如下：
public class MyInterceptor implements Interceptor{
private Session session;
private String userID;
private Set insertSet = new HashSet();
private Set updateSet = new HashSet();
public boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) throws CallbackException{
if(entity instanceof TUser){
insertSet.add(entity);
}
return false;
}
public boolean onFlushDirty(Object entity, Serializable id, Object[] currentState, Object[] previousState, String[] propertyNames, Type[] types) throws CallbackException{
if(entity instanceof TUser){
updateSet.add(entity);
}
return false;
}
public void postFlush(Iterator entities) throws CallbackException{
try{
if(insertSet.size()>0){
AuditDAO.doLog(“insert”, userID, insertSet, session.connection());
}
if(updateSet.size()>0){
AutitDAO.doLog(“update”, userID, updateSet, session.connection());
}
}catch(HibernateException e){
e.printStackTrace();
}
}
…
}可以看到，在onSave、onFlushDirty方法中，我们对发生改变的数据对象进行了记录，并在postFlush方法中将所有这些操作记录到库表中。
对应的Session级代码如下：
SessionFactory sessionFactory = cofig.buildSessionFactory(); MyInterceptor it = new MyInterceptor(); session = sessionFactory.openSession(it); it.setSession(session); it.setUserID(“CurrentUser”); TUser user = new TUser(); user.setName(“Erica”); Transaction tx = session.beginTransaction(); session.save(user); tx.commit(); session.close();
AuditDAO.doLog方法在这里实现了操作日志记录的功能，但我们注意到，这里并没有直接利用当前的session，而是转而利用了当前Session的JDBC Connection引用。session.connection()
之前曾说过Lifecycle和Interceptor中都不能调用当前Session进行操作，Lifecycle和Interceptor接口中定义的方法，都将由当前Session负责调用，而如果在这些方法中又调用了当前Session进行持久化操作，则将导致Session内部状态的混乱。
很容易得到的一个思路就是在AuditDAO中获取一个新的Session实例完成持久化操作。显然这个思路逻辑上完全正确，但是从性能方面考虑，一个操作需要两个Session完成，也就意味着需要同时独占两个数据库连接，这对并发量较大的系统来说可能有点奢侈。
既然当前Session实例无法重用。重用当前Session的数据库连接多少能减少一点性能损耗。
于是有了以下代码：
public static void doLog(String action, String userID, set modifySet, Connection connection){
Session tempSession =
HibernateUtil.getSessionFactory.openSession(connection);
try{
Iterator it = modifySet.iterator();
while(it.hasNext()){
TUser user = (TUser)it.next();
TAuditLog auditLog = new TAuditLog();
auditLog.setUserID(userID);
auditLog.setAction(action);
auditLog.setComment(user.toString());
auditLog.setLogTime(getCurrentTime());
tempSession.save(auditLog);
}
tempSession.flush();
}catch(Exception ex){
throw new CallbackException(ex);
}finally{
try{
tempSession.close();
}catch(HibernateException ex){
throw new CallbackException(ex);
}
}
…
}这样，通过SessionFactory.openSession(Connection dbconn)方法，依托当前Session的JDBC Connection，我们创建了一个临时Session实例用于保存操作记录。
值得注意的是，在AuditDAO.doLog方法里，我们无需再启动事务，原因就在于临时Session中的JDBC Connection是与执行Interceptor的Session所共享的，而在此JDBCConnection上事务已经在外围逻辑代码中启动。
同样的道理，由于共享JDBCConnection，我们也无需执行close操作。
Interceptor提供了非侵入性的拦截器实现机制。基于这种机制，我们可以以更加灵活的方式实现传统数据逻辑中的一些特殊需求。在实际开发中，我们可以根据自己的需求进行相应的调整。
在Hibernate3中，提供了基于时间监听Listener机制的拦截器实现。这种方式可以提供比Interceptor更加清晰合理的实现模型。由于实现方法大同小异，这里不再赘述，大家可自行评判。
