在Hibernate中使用HibernateTemplate的三种方法

正解，好多的书籍，视频都是这样、那样说，持久化一定需要分出个层来，然后很多人就以为非要自己写个dao代码，才算分个层出来，这样才解耦，殊不知hibernateDaoSupport就已经是一个dao层，在大部分并不是十分十分复杂的项目中，将hibernate再封装一下，给services使用，而每个dao方法里面却只有一行的代码。写方法头的代码和方法体的代码一样多，美名其曰这叫封装。。。。我很无语。。。

不喜欢注解
特别那些刚刚接触框架的就学注解，，，虽然能看到最后的效果。。。其实很多根本不知道到底是怎么一回事。。。。

你的理解是错的。

DAO这层可以很薄，但是要有。把SQL和HQL写在配置文件里是一个非常差的实践。会为调试和问题定位带来极大的麻烦。

如果我不是需要经常再不改动代码的情况下改动hql的需求，我会直接放在业务逻辑类里面。这是最理想的位置
谁说hql是属于dao层的呢？hql是属于业务逻辑的，它经hibernate转换后成变成的sql才属于dao层里面的东西。而hibernate的这个转化过程就是你在“调用dao层”
我不会直接写sql的，这违背hibernate本意，如果hql等。。实在满足不了需求，写sql是必然，但一个项目中这样的位置不会超过两处，这是技术上的问题，如果非要为这两处封装一个dao，得不偿失，假如需要写很多hql满足不了的sql，也可以考虑自己写个补充hibernate的hql解释器，而不是直接写sql并将他放在代码里面。

hql确实是业务层的东西，这个应该写在service里面，必须的sql放配置没什么问题，这个比放代码里面更干净，更容易调试。dao是jdbc时代遗留产物，不过为每一个sql的执行和把执行结果放入对象这样的操作做一个命名而已。在使用hibernate,jpa同时大量使用dao,才是一个很差的实践。所谓很薄的dao,为什么不直接用session或者jpa里面的entityManager代替，封装一下减少功能很有意思么？

<bean id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
<property name="sessionFactory" ref="sessionFactory" />
</bean>
<bean id="transactionManager"       class="org.springframework.orm.hibernate3.HibernateTransactionManager">
  <property name="sessionFactory" ref="sessionFactory" />
</bean>
<tx:annotation-driven transaction-manager="transactionManager" />

然后
   @Resource protected HibernateTemplate hibernateTemplate;
   可以让BaseDAOImpl的子类也可以使用hibernateTemplate

this.hibernateTemplate.findByCriteria(DetachedCriteria.forClass(entityclass));
Hibernate提供的DetachedCriteria 可以在没有Session的情况下组装查询条件，这样将HQL转换为QBC，业务就可以脱离DAO，在Service层写好DetachedCriteria再统一使用hibernateTemplate.findByCriteria进行处理，感觉这样比较好

So,直接把hibernateTemplate放service里面好了，简单易用，维护方便。

你认为DAO没有存在的必要性，主要是因为你做的项目还不够复杂。

在一个Service调用中，业务逻辑可能会包含十几次的数据库调用，其中有一半需要用HQL。你告诉我你把这些HQL全部写在Service层，那么你的Service层就会膨胀不堪，代码就会变得不可读。DAO层的出现，可以把这些HQL的数据库调用封装起来，让你的代码更加简洁。同时，这些被封装的函数，可以被反复调用。

HQL或者SQL写在配置文件里面是一种非常错误的做法。项目很大的时候，你会发现你的配置文件中充斥着非常类似的HQL或者SQL。同时，在你进行debug调试的时候，由于你拿到的是一个Key，增加了一个根据Key到配置文件去拿HQL的动作，从而给调试带来不便。

一个业务逻辑包含十来个数据库调用扥情况，如果你将这些业务逻辑只是写在一个service里面，没有进行横向的模块划分的话的确会很复杂，会膨胀不堪，会不可读，但这却不是因为没有dao层的原因，而是由于你设计的问题，安我的经验，一个业务逻辑中的十来次数据库操作，而且都是很复杂的数据库操作，通常这样的逻辑可以再拆分成更细化的逻辑，而且有一部分逻辑是属于其他模块的业务逻辑，完全可以抽象出来放在其他模块的services里面，这样也可以拿来复用。
因为services层的臃肿不堪就把业务层的东西放到dao层里面，也就是你所说把hql封装起来的函数级别的复用其实是低级的复用，把hql和此hql对应的方法逻辑封装到一起，形成services级别的复用才是最好的解决方案。

这个不是绝对的，还应该具体问题具体分析吧。
如果系统比较复杂庞大，并且以后有换数据库的可能性，还是写一个dao层对日后是有好处的。
如果只是一般的系统并且数据库不会换掉可以考虑写一个自己的BaseDao。