写程序，做产品，过日子

1.HibernateTemplate提供持久层访问模板化
2.使用HibernateTemplate无须实现特定接口，它只需要提供一个SessionFactory的引用，利用aop注入到dao就可以实现对持久层的操作
3.整合事物操作就已经是它存在的最好的理由了,还想要什么?  回复  更多评论
  

@aninggo
我想知道的是，和直接使用hiberate API相比，有什么好处？不用HiberateTemplate，同样能整合事务，而且一样简单。  回复  更多评论
  

@Welkin Hu
虽然可以通过注入使用hibernate的原生API，但是还是有风险的，一旦该方法没有被事务包装起来，那么session最后就没有办法被自动关闭掉，这不像使用template，总可以被关闭掉，不管有没有事务封装。
而且joson说过 ，template的主要目的是提供一个统一的持久层访问接口.用不用完全看个人喜好,学习这个api的曲线不会太陡峭吧:)  回复  更多评论
  

@aninggo
这么说主要好处是保证自动关闭session。这个的确很有用。
至于第二点，Jason想到的是方便用户从一种持久层技术切换到另一种。而在我们的产品中，持久层比较稳定，反倒是Spring，有可能被换掉。出发点不一样啊。  回复  更多评论
  

@Welkin Hu
并不是你没有用它就没有存在的必要,会有人用到的,spring不也给你了不同它的方法了么.  回复  更多评论
  

最大的作用应该是切换持久层框架。比如说最常见的同时用hibernate和原生jdbc，很多项目都会用到。  回复  更多评论
  

@netfishx
应当有往这个方向努力的目的，但还达不到。原因很简单，各个持久层的查询语言和模型不一致，比如HQO，SQL, JDOQL, JPQL, Criteria等等。Spring的Template虽然统一了API的方法名和参数个数，但其接收的参数本身仍是分裂的。  回复  更多评论
  

今天被Spring的事务管理机制耍了，不得临时用用HibernateTemplate。一用才发现简单的查询被Spring搞复杂了，而且缺失了一些功能。
1，不支持分页。HibernateTemplate中有个fetch size，但没有first result。
2，传入命名参数时不是一个map，而是一个名称数组和一个值数组。
3，传入参数为null时有异常。

当然，解决办法很简单——写一个新类扩展HibernteTemplate。

此外，Spring参数文档中对HibernateTemplate的用法举例也有问题。在它的例子中，每个DAO类都有一个HiberanteTemplate属性，而不是每个DAO的方法自己创建一个新的HibernateTemplate实例。
这种做法的主要问题在于，HibernateTemplate中的一些设置，如fetch size, max results等，可能在调用者不知情的情况下，应用到后续查询中。

我现在更愿意把HibernateTemplate理解成Spring集成Hibernate的一个sample。想用就用，想改就改。  回复  更多评论