有了hibernate是否还需要Dao?

最近学习使用Struts2+Hibernate，也是分层，web层里放Struts2的action
service层里放业务逻辑对象，持久层里放的是dao+po，对po操作基本放到了dao里，可以我不解的是使用Hibernate的方法我返回本身就是po，为什么大家写程序的时候还写dao呢？我的dao里对po的操作几乎把它细分到了一个方法仅仅一次crud,我通过调用不同的dao里多次方法来实现业务中需要对不同的po进行多次的crud操作的情况，每调用一次dao的一个方法开个session然后对po进行一次crud操作又关session，那么session的缓存不是基本没什么作用了吗？还有一个问题就是通常po对应了一dao又对应了一service，我的dao的方法分的比较细（一个方法仅仅对po进行一次crud），我感觉我的service里仅仅只是重复调用了一遍dao的方法，然后在action中调用service层里不同的service对象实现稍微复杂的业务，我想过是不是service是用来把不同的dao的方法结合起来实现业务中需要对不同的po进行多次的crud操作的情况？这样在action中只要调用service中的方法那action里的代码就清爽了。但是我的action我也分的比较的细，一个action只针对用户的一步操作（多步操作可以用action chain串起来），一个页面可以有不同的action为用户不同的请求服务，action也是根据用户的一步操作命的名，我觉得根本不要把对action的多次操作的这样的业务放到service中，我想去掉service层直接在action中调用dao，原因是我的action是根据用户的一步业务操作命名，作为业务逻辑也好理解，几步操作可以用action chain，原因二是少了service层不用把数据又传到service层再调用一遍，原因三按照 黑体部分（见上面） 的考虑service到是有事情干了，可action干什么呢，难道是为了调service而存在的吗？？关于web+service+dao+po这样的分层大家能能简单的说明下那三层究竟各负责什么，另外我知道要根据项目的具体情况合理分层，但我始终不明白service层的具体作用。
归纳下我的疑问：
1使用Hibernate的方法我返回本身就是po，为什么大家写程序的时候还写dao呢？我的dao里对po的操作几乎把它细分到了一个方法仅仅一次crud，每个方法一开session一关session，session的缓存不是几乎形同虚设了吗？
2我的web层的action我也分的比较的细，一个action只针对用户的一步操作（多步操作可以用action chain串起来），是否还需要service层？为什么？
3web（细，struts2支持按namespace对action划分）+service（使用Hibernate实现业务逻辑，稍复杂业务逻辑可以对不同po crud多次可以利用到session缓存）+po 一般情况的项目是不是这样分层更好一些呢？

评论

49 楼 yujianqiu 2008-04-18  

简单说两句关于DAO的看法。
我觉得如果对Persistent的理解已经到了JPA的时代，那么DAO是不需要的，甚至是不能要的。

先说为什么不需要。
持久的目的是什么？是存储对象的瞬时状态。将其简单理解为对数据库的ＣＲＵＤ是比较狭隘的。如果，内存足够大、计算机永远不会断电，程序员永远不反错误，那么可以不去持久化。
以JPA（Hibernate）的观点来看，一个对象只有两种状态：持久的和非持久的。让一个非持久的对象变为持久对象只需调用persist()方法将其加入持久域；让一个持久的对象变为持久对象则调用remove()方法使其脱离持久域；如果让一个持久对象刷新其状态就调用flush()方法；如果想undo那么就refresh()。至于那些烦人琐事，让Hibernate那个倒霉蛋去干吧。事情就是这么简单。
如果看透了这一点，那么DAO就可以去光荣下岗了。

再说为什么不能要。
这个解释起来很简单，看看代码就知道了。

public class Person {
    private int id;
    private List<Something> things;
    ...
}
public class Something{
    private int id;
    private Person owner;
    private String name;
    ...
}

很简单的一对多关联，与之对应有了PersonDao和SomethingDao，它们是的实现类中用Hibernate完成CRUD。
来看看“R”吧，它就是把DAO送进坟墓的人。

public void doSomething() {
    Person me = personDao.get(myId);
    //我可以这样做吗？
    List<Something> myThings  = person.getThings();
    //还是要这样做？
    myThings = somethingDao.getThingsOf(me);
}

如果你不想在Hibernate一棵树上吊死，那么就用JPA吧。如果你也不想在JPA上吊死那就自己定义一个XXXPA也可以。不过，在这之前，先认真地想一想你所知道的软件的生命周期内是不是真的会换掉Hibernate呢？

48 楼 fzhq1970 2008-03-18  

楼主说的有道理，但是在想想，采用dao service的主要目的有两个：实现系统的分层，降低模块之间的耦合度。如果不用dao，将是你的应用服务层service同hibernate机密的集合起来，如果不要service，你的action同样同和ibernate或者jdbc机密结合，增加模块之间的耦合度，而且降低了模块的重用性。我估计你开发的是一个较小的系统，大型系统像你说的那样，可定带来很多不必要的重复代码编写，带来极大的维护难度，也不宜与调试和排错，更不用说将来的系统扩展。

47 楼 昨日辉煌 2008-03-09  

抛出异常的爱 写道

zbird 写道

就个人而言，我不喜欢DAO。
DAO不是万能药，解耦并不是加个DAO就能解决的问题。
对于大多的简单操作，Hibernate封得已经够完善了，大多时候加个DAO费力不讨好。
如果操作复杂，Service层过于混乱，这时候再抽取出个DAO也没什么不可以。
说到使用DAO解耦，大家最喜欢举的例子就是换实现。以前是说换数据库，现在Hiberate对数据库封得差不多了。于是说法改成将hibernate换成其他的实现，如jdbc等。
但真实项目中有谁有事没事的去换这些东西。
耦是有了才需要解的，如果凭空想出很多不实在的需求，无非是给自己自找麻烦。

我一直在说....
不是为了移植
而是为了管理方便

当然你可以把业务逻辑
与数据库逻辑写在一起
当只有一二个表时
并没什么不好解理
当一个操作关系到:
日志表,
权限表,
业务级联表,
操作记录表,

用人类的智力要从这么多的代码中找到逻辑.....还是差点意思

大哥的理解确实很高，多谢了

46 楼 nighthawk 2008-03-02  

先说句废话:要根据实际情况决定.
不过根据楼主描述的现象,我个人倾向于不要这种细粒度DAO层,做个公共的DAO对hibernate进行一次封装就可以了.

45 楼 ccs57567300 2008-03-01  

我相信,DAO只是为了方便大家去维护和更新,能让人一目了然而已

44 楼 christensen 2008-01-24  

有的时候是为测试考虑

43 楼 hellostone 2008-01-21  

其实还是很有必要分层的。如果你尝试从没有任何框架 直接在页面上写JDBC 实现一些简单的功能，然后准备在这之上增加一些功能 的话 你会发现分层的意义了。

42 楼 spiritfrog 2008-01-20  

对于lz的问题：
1.dao的出现本来是解耦业务层和数据的操作的，你这里比较简单，可能简单到一句话，但还是保留dao比较好，难保会有复杂的情况吧。
2.一个action，一个crud操作而已，那么确实可以省略service，还是老话，因为上面的理由，还请在适当的时候保留service。
3.web+service，service中多次crud重用一个session；这样是可以的。
由此看出其实三个问题都是一个问题，就是该不该解耦dao和service，简单的情况下，当然会找理由说服自己别那么麻烦，但是复杂的情况就会发现这么做的价值了。

41 楼 dengyin2000 2008-01-18  

dmewy 写道

解耦合这个是最重要的.
分层不清楚的话以后扩展很难的.
现在做程序不是说实现功能就OK的.
一个程序百分之80的生命周期是在维护.
要长期考虑.
J2EE最正规是18层架构.

这些都是他妈的客套话。

40 楼 dmewy 2008-01-18  

解耦合这个是最重要的.
分层不清楚的话以后扩展很难的.
现在做程序不是说实现功能就OK的.
一个程序百分之80的生命周期是在维护.
要长期考虑.
J2EE最正规是18层架构.

39 楼 zlkn2005 2008-01-18  

要，我觉得肯定要。
Hibernate和Dao所扮演的角色是不同的。
Dao是项目的数据维护层，不可以用简单的Hibernate去替代。他所处理的并不单单只是数据库的数据。

38 楼 抛出异常的爱 2008-01-17  

bianqioujin 写道

关于你说的那个session 的问题，你可以在spring 中指定，当程序进入action 的时候就开启session  ,我现在的项目就是这样用的  struts2+spring+hibernate

如果当初struts不是 那么难以测试的话.人们为什么开发service层呢?

37 楼 bianqioujin 2008-01-17  

关于你说的那个session 的问题，你可以在spring 中指定，当程序进入action 的时候就开启session  ,我现在的项目就是这样用的  struts2+spring+hibernate

36 楼 jackzhangyunjie 2008-01-17  

说实话，我觉得DAO和Services的存在就是为了把持久化层和业务层进行分离，软件开发的理想就是代码的无限重用，为什么实现代码的无限重用，一个好的方式就是写一些与具体框架没有关联的方法，这样如果不用这个框架的话，那些代码完全可以分离出来再去用在别的地方

35 楼 pig345 2008-01-17  

有更好的选择，让你既抛开DAO，又能隔离hibernate.

http://pig345.iteye.com/blog/79822

34 楼 whilew 2008-01-15  

不知道大家对于OO编程中的依赖倒置这条原则的见解如何，从我个人的观点来看，良好的分层体系为实现这种依赖倒置也提供了方便之处，依赖倒置为解除之间的高耦合提供了方案。在系统中加入一个中间层，使你整个系统的架构更加灵活，更能快速高效优质地响应未知的变化，从而拥抱变化。

33 楼 lsj19830812 2008-01-15  

看了些回帖,总结如下,对不对?


举例:添加某条记录完成后显示新的列表页面
(
两步操作:
1.添加
2.查询列表
)
Action  控制工作流,只调用一个RecordsService,里面不写业务逻辑,这里的控制只控制页面的不同跳转,尽量不写Action的逻辑跳转,以免更改web层实现框架需要重写业务逻辑.

Service 实现业务逻辑,  提供具体服务,RecordsService提供添加和查询列表功能,这两个功能是按照业务逻辑将DAO的实现拼凑写在一个方法中,如果需要改动业务逻辑,只需要调用不同的DAO的方法,不需要改动Action.

DAO 实现对PO的访问,不写业务逻辑,写具体的小功能(添加,查询)每个功能写为一个方法,提供给Service调用.

Session放在Service层管理,不放在DAO层.

32 楼 ssxxue 2008-01-14  

<div class='quote_title'>tczengjin 写道</div><div class='quote_div'>最近学习使用Struts2+Hibernate，也是分层，web层里放Struts2的action<br/>service层里放业务逻辑对象，持久层里放的是dao+po，对po操作基本放到了dao里，可以我不解的是使用Hibernate的方法我返回本身就是po，为什么大家写程序的时候还写dao呢？我的dao里对po的操作几乎把它细分到了一个方法仅仅一次crud,我通过调用不同的dao里多次方法来实现业务中需要对不同的po进行多次的crud操作的情况，每调用一次dao的一个方法开个session然后对po进行一次crud操作又关session，那么session的缓存不是基本没什么作用了吗？还有一个问题就是通常po对应了一dao又对应了一service，我的dao的方法分的比较细（一个方法仅仅对po进行一次crud），我感觉我的service里仅仅只是重复调用了一遍dao的方法，然后在action中调用service层里不同的service对象实现稍微复杂的业务，<strong>我想过是不是service是用来把不同的dao的方法结合起来实现业务中需要对不同的po进行多次的crud操作的情况？这样在action中只要调用service中的方法那action里的代码就清爽了。</strong>但是我的action我也分的比较的细，一个action只针对用户的一步操作（多步操作可以用action chain串起来），一个页面可以有不同的action为用户不同的请求服务，action也是根据用户的一步操作命的名，我觉得根本不要把对action的多次操作的这样的业务放到service中，我想去掉service层直接在action中调用dao，原因是我的action是根据用户的一步业务操作命名，作为业务逻辑也好理解，几步操作可以用action chain，原因二是少了service层不用把数据又传到service层再调用一遍，原因三按照 黑体部分（见上面） 的考虑service到是有事情干了，可action干什么呢，难道是为了调service而存在的吗？？关于web+service+dao+po这样的分层大家能能简单的说明下那三层究竟各负责什么，另外我知道要根据项目的具体情况合理分层，但我始终不明白service层的具体作用。<br/>归纳下我的疑问：<br/>1使用Hibernate的方法我返回本身就是po，为什么大家写程序的时候还写dao呢？我的dao里对po的操作几乎把它细分到了一个方法仅仅一次crud，每个方法一开session一关session，session的缓存不是几乎形同虚设了吗？<br/>2我的web层的action我也分的比较的细，一个action只针对用户的一步操作（多步操作可以用action chain串起来），是否还需要service层？为什么？<br/>3web（细，struts2支持按namespace对action划分）+service（使用Hibernate实现业务逻辑，稍复杂业务逻辑可以对不同po crud多次可以利用到session缓存）+po 一般情况的项目是不是这样分层更好一些呢？ </div><p><br/>1.解耦，道理上面很多朋友都给你解释了，不多说。如果觉得单纯字面上理解起来有困惑，可以去看看struts2-showcase里关于skill,employee那个例子的具体实现（记不太清楚了，呵呵）</p><p>复杂的商业逻辑中，一个事物会包含对于数据库多次的读写操作，dao中的每一个方法都开关session的话你如何处理此类事务？</p><p>2.清晰的层次结构会对你将来对系统的更新以及维护工作带来许多方便,该放在service层的逻辑你当然也可以放在action中或者dao层里，举例说，比如用户在页面操作，触发以下逻辑：找出当天所有系统应该通知的人(po)，发送email且，更新这些人的某些属性。此类商业逻辑放在action或者dao中，都是不妥的，我想这就是service层存在的理由。</p><p>3.同1，解耦，dao层存在的理由是与persistent解耦，让你的项目不具体的依赖某一种persistent实现。可替换的persistent带来很多好处，比如对于简单的系统，你可以用mock写写原型什么的，功能，ui都可以实现，仅仅需要换掉persistent层就是一个大概成型的系统了。</p><p> </p>

31 楼 soleegn 2008-01-14  

我认为这个问题有点类似与“吃饭是否一定需要筷子？”

30 楼 yangjianfeng 2008-01-14  

你的service中可以不用写前面两个方法呀，getBooks中直接调用dao中的两个方法，放在一个事务中