由一段代码引起的

  最先接触hibernate关于业务的操作都是通过session操作的，好长时间没有用，再去看代码的时候发现一些看不懂的地方。先看看代码 

        return (List) this.getHibernateTemplate().execute(
                new HibernateCallback()
                {
                    public Object doInHibernate(Session session)
                            throws HibernateException, SQLException
                    {
                        Query query = null;
                        query = session
                                .createQuery("from TsMoniSession session where 1=1");
                        return query.list();
                    }
                });

 

项目中的代码大量的充斥着这种写法，每一个操作都是通过callback去调用hibernate的方法，这个callback到底是个什么原理，但是明明template明明也提供了更为简单的find方法，为什么不去用呢？先去理解理解callback吧。

    如果是一个初学者，在碰到下面一个问题的情况下会采取什么样的解决方法。

    问题：boss要他计算一下程序中的10个方法的计算时间成本，记录到日志中去。

    方案1：这还不简单，每个方法前面加上开始时间，结尾加上结束时间，然后取差就

     可以了。代码如下：

    

  long before=System.currentTimeMillis(); 
  method1(); 
  long after=System.currentTimeMillis(); 
  log.info("the cost is:"+(after-before));

 

 

 

  非常对，这个解决办法很好的达到目的。但是问题出来了，如果是有1000个这样的方法，工作量就很大了。而且即使十个方法而言，代码本身就有大量重复的代码，这就意味着有可以改进的地方。想象一下：我们（开发者）在使用method的时候都是直接去调用，如果在这个中间可以加一层，然后这个层是对方法可以包装的话，是不是就可以减少那么多重复的代码量呢。我们暂时把它叫做TemplateMethod吧. 那怎么设计呢？难不成我们调用method的时候把方法名作为参数传进去。

方案二：

public void doMethod(String methodName, Object[] parameters)
	{
		long before = System.currentTimeMillis();
		利用java反射执行method
		long after = System.currentTimeMillis();
		log.info("the cost is:"+(after-before));
	}

 

   虽然很好的解决了代码量重复的问题，但是怎么看怎么别扭，因为他完全改变了使用者原先调用方法的习惯，为了计算成本不得不换成后来的调用方式，实在是一种不太优雅的设计。

  接口，接口，设计模式这些都是设计优雅的程序的基本，来看看一个即不改变原先调用习惯，又能节省代码的设计。

   CallBack.java 

public interface CallBack
{
    public void doInMyMethod();
}

  

  TemplateMethod.java

public class TemplateMethod
{
	public void computeCost(CallBack callback)
	{
		long before = System.currentTimeMillis();
		callback.doInMyMethod("");
		long after = System.currentTimeMillis();
		log.info("the cost is:" + (after - before));
	}
}

  

   再看看我们都怎么使用templateMethod去调用我们的方法

 

 如此的调用方式基本上已经达到了目的了，是不是很熟悉，和本文开头的hibernate的回调很像，没错，spring的设计正是想让使用者还是能像以前使用session操作一样去操作hibernate，不同的是hibernate template已经帮我们做好一些其他的事情了，比如session的获取，session的flush等等。不仅仅是hibernate，ibatis都是有这样的template。到这里我们总算清楚了callback的一点内幕了，再看看为什么使用者为什么用这种方式而不用template的find方法，根据我的理解

1.   习惯问题，习惯了seesion的使用方式
2.    如果一个业务操作既要查询，又要修改，删除的，如果用template的方法的话，效率显然要低点（如果看看hibernateTemplate的源代码的话，template的方法也是通过回调调用hibernate的方法，只不过包装的更好了），所以干脆就用回调使用hibernate了

回到那个计算时间成本的例子，当然最好的方法是通过spring的aop了，这就是框架的方便之处。