`

在Hibernate中使用HibernateTemplate的三种方法

阅读更多
在我们的项目中,经常要从HibernateDaoSupport继承然后使用他的HibernateTemplate给我们封装好的方法。

我们以用户模块的持久层UserDao这个类的addUser(User user)方法为例:

第一种方法:userDao extends HibernateDaoSupport:(不推荐使用)
我们知道继承这个类,必须给他注入一个HibernateTemplate的对象,或者是SessionFactory对象但是HibernateDaoSupport这个类的所有的方法都是final的,无法重写他的setSessionFactory(SessionFactory sessionFactory)方法来注入,只能使用xml的方式来生成userDao这个对象的时候,使用<property id ="xxx" ref="xxx">来注入这个对象,但是如果这样,如果我们的Dao层的类特别多,都需要在xml文件中进行配置我们的xml配置文件就会十分的庞大 臃肿

第二种方法:
public class BaseDao extends HibernateDaoSupport {
	
	@Resource(name="sessionFactory")
	public void setSF(SessionFactory sessionFactory) {
		super.setSessionFactory(sessionFactory);
	}
}

我们抽取出来一个Dao层的基类然后让这个类继承HibernateDaoSupport,然后我们自己随便写个方法参数是SessionFactory,然后再方法上面加入@Resource注解,把SessionFactory对象,注入到这个方法中来然后再这个方法中调用父类中也就是HibernateDaoSupport 中的setSessionFactory(SessionFactory sessionFactory)方法把sessionFactory给他注入进去。默认情况下@Resource注解是按照名称来注入的,但是这个时候我们自己写的这个方法无法与spring配置文件中的id名称匹配起来就会按照类型进行注入了。然后我们的UserDao类继承我们的BaseDao类就可以使用HibernateTemlate中的方法了。

第三种方法:
public class BaseDao {
    private HibernateTemplate hibernateTemplate;
    @Resource
    public void setHibernateTemplate(HibernateTemplate hibernateTemplate) {
         this.hibernateTemplate = hibernateTemplate;
}	
}


还是抽取出一个BaseDao的类,然后我不继承HibernateDaoSupport这个类了。我在这个类中,定义一个HibernateTemplate类型的属性,然后把这个类注入进来,UserDao等这些持久化类仍然是从这个类继承,就可以使用HibernateTemplate中的方法了。
分享到:
评论
24 楼 javaliver 2010-06-13  
slaser 写道
whaosoft 写道
star022 写道
这年头 还这么多人玩DAO啊~~!

为什么不玩DAO了啊?

DAO没什么意义。
1.我只用hibernate。
2.我不换数据库。
3.sql和hql大部分写配置文件里面。
如此为什么不直接把session注入到service里面直接操作?



ession注入到service里面直接操作????
23 楼 slaser 2010-04-20  
aws 写道
ORM工具在简化单表动态查询和CRUD的时候作用很大
但是复杂查询用HQL之类的那就太过于麻烦了,还不如直接写SQL
至于一个业务逻辑里十几次操作数据库,这往往直接就写成存储过程了

对于很多遗留系统或者说设计时不是很考虑orm工具特性的系统,视图,存储过程等是不二法宝。处理非OO数据,java该歇一边去。
22 楼 slaser 2010-04-20  
downpour 写道
你认为DAO没有存在的必要性,主要是因为你做的项目还不够复杂。

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

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

没看出来根据key拿hql那里麻烦了,除非key和对应的query命名非常混乱。如果合理运用named query,java代码和hql/sql相分离,将会大大减低维护工作的难度,拿sql来说,你说DBA喜欢看你java中拼出来的sql,还是单独配置文件中的sql?同样作为java程序员的我,在view代码的时候,看到一大串sql进来插入java中,我也非常无语。
21 楼 slaser 2010-04-20  
ysihaoy 写道
slaser 写道
aaa5131421 写道
downpour 写道
aaa5131421 写道

正解,好多的书籍,视频都是这样、那样说,持久化一定需要分出个层来,然后很多人就以为非要自己写个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代替,封装一下减少功能很有意思么?


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

我是基于不换数据库,不换orm工具来说的。没有限定条件,一切都是空谈。
20 楼 aws 2010-04-20  
ORM工具在简化单表动态查询和CRUD的时候作用很大
但是复杂查询用HQL之类的那就太过于麻烦了,还不如直接写SQL
至于一个业务逻辑里十几次操作数据库,这往往直接就写成存储过程了
19 楼 ysihaoy 2010-04-20  
slaser 写道
aaa5131421 写道
downpour 写道
aaa5131421 写道

正解,好多的书籍,视频都是这样、那样说,持久化一定需要分出个层来,然后很多人就以为非要自己写个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代替,封装一下减少功能很有意思么?


这个不是绝对的,还应该具体问题具体分析吧。
如果系统比较复杂庞大,并且以后有换数据库的可能性,还是写一个dao层对日后是有好处的。
如果只是一般的系统并且数据库不会换掉可以考虑写一个自己的BaseDao。
18 楼 aaa5131421 2010-04-20  
downpour 写道
你认为DAO没有存在的必要性,主要是因为你做的项目还不够复杂。

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

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

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

HQL或者SQL写在配置文件里面是一种非常错误的做法。项目很大的时候,你会发现你的配置文件中充斥着非常类似的HQL或者SQL。同时,在你进行debug调试的时候,由于你拿到的是一个Key,增加了一个根据Key到配置文件去拿HQL的动作,从而给调试带来不便。
16 楼 slaser 2010-04-20  
jackerxff 写道
<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里面好了,简单易用,维护方便。
15 楼 jackerxff 2010-04-20  
<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进行处理,感觉这样比较好
14 楼 slaser 2010-04-20  
aaa5131421 写道
downpour 写道
aaa5131421 写道

正解,好多的书籍,视频都是这样、那样说,持久化一定需要分出个层来,然后很多人就以为非要自己写个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代替,封装一下减少功能很有意思么?
13 楼 aaa5131421 2010-04-20  
downpour 写道
aaa5131421 写道

正解,好多的书籍,视频都是这样、那样说,持久化一定需要分出个层来,然后很多人就以为非要自己写个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并将他放在代码里面。
12 楼 downpour 2010-04-19  
aaa5131421 写道

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


你的理解是错的。

DAO这层可以很薄,但是要有。把SQL和HQL写在配置文件里是一个非常差的实践。会为调试和问题定位带来极大的麻烦。
11 楼 bavnnsym 2010-04-19  
不喜欢注解
特别那些刚刚接触框架的就学注解,,,虽然能看到最后的效果。。。其实很多根本不知道到底是怎么一回事。。。。
10 楼 aaa5131421 2010-04-19  
slaser 写道
whaosoft 写道
star022 写道
这年头 还这么多人玩DAO啊~~!

为什么不玩DAO了啊?

DAO没什么意义。
1.我只用hibernate。
2.我不换数据库。
3.sql和hql大部分写配置文件里面。
如此为什么不直接把session注入到service里面直接操作?

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

多数人都是自己封装个baseDao 然后注入到service...
8 楼 slaser 2010-04-19  
whaosoft 写道
star022 写道
这年头 还这么多人玩DAO啊~~!

为什么不玩DAO了啊?

DAO没什么意义。
1.我只用hibernate。
2.我不换数据库。
3.sql和hql大部分写配置文件里面。
如此为什么不直接把session注入到service里面直接操作?
7 楼 whaosoft 2010-04-19  
star022 写道
这年头 还这么多人玩DAO啊~~!

为什么不玩DAO了啊?
6 楼 xhbyy 2010-04-19  
怎么这么多人喜欢用注解呢? 配置文件的作用是什么,就是为了可扩展性,注解写在类里,和直接用new的有什么区别?  你的DAO配置里就不能加个属性parent="BaseDao"吗?
5 楼 star022 2010-04-19  
这年头 还这么多人玩DAO啊~~!

相关推荐

    对hibernate的封装 HibernateTemplate

    在使用HibernateTemplate之前,需要配置SessionFactory,并将其注入到HibernateTemplate实例中。以下是一个简单的例子: ```java @Autowired private HibernateTemplate hibernateTemplate; public void saveUser...

    HibernateTemplate的方法使用

    **HibernateTemplate** 是 Spring 框架中用于简化 Hibernate 使用的一个工具类。它通过 AOP(面向切面编程)的思想,封装了大量的 CRUD(创建、读取、更新、删除)操作,使得开发者能够更加专注于业务逻辑的实现,而...

    Spring_Spring_Hibernate_HibernateTemplate

    在Java企业级开发中,Spring框架和Hibernate持久层框架的结合使用是常见的技术选型。本篇将深入探讨Spring与Hibernate的集成,特别是Spring提供的HibernateTemplate,它是Spring对Hibernate的一种封装,简化了数据库...

    hibernateTemplate的常用方法

    `HibernateTemplate`是Spring框架中用于操作Hibernate的一个便捷工具类,它极大地简化了Hibernate在实际应用中的集成与开发工作。通过`HibernateTemplate`,开发者可以非常方便地进行数据的增删改查等基本操作,而...

    关于使用HibernateTemplate

    3. **异常处理**:当使用`HibernateTemplate`执行数据库操作时,它会自动捕获并处理Hibernate抛出的各种异常,从而减轻了开发者在异常处理上的负担。 #### 三、声明式事务管理 `HibernateTemplate`支持声明式事务...

    HibernateTemplate汇总

    HibernateTemplate 是 Spring 框架中的一個关键组件,用于简化 Hibernate 的使用,提供了許多实用的方法来进行数据库操作。在本文中,我们将对 HibernateTemplate 的主要方法进行总结和解释。 ...

    Spring_2000_Spring_Hibernate_HibernateTemplate

    读者可以通过这个文档了解Spring和Hibernate在2000年左右的版本中的使用,以及如何有效地利用HibernateTemplate进行数据操作。 总结来说,这个主题涵盖了Spring框架的基本原理、核心特性,以及在2000年左右如何与...

    HibernateTemplate详细描述以及使用范围

    在Spring框架中,`HibernateTemplate`作为ORM(Object Relational Mapping)技术中的一个重要组件,它提供了简化Hibernate操作的方法集,使得开发人员能够更加便捷地进行数据库操作。通过使用`HibernateTemplate`,...

    Spring中使用Hibernate

    以上就是在Spring中使用Hibernate的基本步骤和关键知识点。通过熟练掌握这些内容,你可以构建出高效、稳定且易于维护的数据访问层。在`Hibernate_Spring`这个压缩包文件中,可能包含了相关的示例代码和配置文件,这...

    hibernate模拟hibernatetemplate

    本教程将深入探讨如何模拟HibernateTemplate,这是Spring框架中的一个辅助类,用于简化Hibernate的使用。在Spring 3.x版本之后,HibernateTemplate被HibernateOperations接口和SessionFactory取代,但在之前的版本中...

    Spring+Hibernate实现增删改查的两种方法

    在Java Web开发中,Spring和Hibernate是两个非常重要的框架,它们常常被联合使用来处理数据库操作,如增、删、改、查(CRUD)。本文将深入探讨如何利用Spring与Hibernate整合,通过两种不同的方式来实现这些基本操作...

    HibernateTemplate 的常规用法.doc

    它为简化Hibernate在Spring框架中的使用提供了便利,减少了手动管理Session和事务的复杂性,提升了开发效率。本节将深入探讨HibernateTemplate的常规用法。 HibernateTemplate提供了丰富的API,可以实现对数据库的...

    HibernateTemplate类的使用

    需要注意的是,直接在`doInHibernate`方法中使用`Session`的事务管理方法可能会导致预期之外的结果,因为这些操作可能与`HibernateTemplate`的默认行为相冲突。 #### 六、Hibernate事务机制探究 为了更好地理解上述...

    SSH2增删改查使用HibernateTemplate

    接下来,我们将深入探讨如何在SSH2中使用HibernateTemplate进行这些基本操作。 首先,我们需要配置SSH2框架。在`applicationContext.xml`中,我们需要配置Spring与Hibernate的整合,包括DataSource、SessionFactory...

    HibernateTemplate的用法总结

    下面通过一个具体的示例来展示如何在实际项目中使用HibernateTemplate。 ```java public class PersonDAOHibernate implements PersonDAO { // log4j日志 private static Log log = LogFactory.getLog...

    Spring整合hibernate(2)之基于HibernateTemplate的整合

    在Java企业级开发中,Spring和Hibernate是两个非常重要的框架,Spring作为一个全面的轻量级容器,负责管理对象的生命周期和依赖注入,而Hibernate则是一个强大的持久化框架,专门处理数据库操作。本教程将深入探讨...

    hibernateTemplate

    `HibernateTemplate`还支持命名查询功能,这是一种预先定义好的查询方式,可以在Hibernate配置文件中预先定义好查询语句及其名称,然后在程序中直接调用这些命名查询,提高了代码的可读性和可维护性。 #### 四、...

    Hibernate方法总结

    在Java持久化框架Hibernate中,HibernateTemplate是一个便捷的工具类,它封装了常见的数据库操作,使得开发者能够更方便地与数据库交互。以下是对标题和描述中提到的HibernateTemplate方法的详细总结: A. `get` 和...

    Spring+hibernate整合源代码

    你可以使用编程式事务管理,即在代码中显式调用 begin/commit/rollback 方法,或者使用声明式事务管理,通过 @Transactional 注解来标记事务边界。 3. **数据源配置**:配置数据源是整合的起点。你需要在 Spring ...

Global site tag (gtag.js) - Google Analytics