有了hibernate是否还需要Dao?

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

这些都是他妈的客套话。

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

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

有的时候是为测试考虑

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

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

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

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

简单说两句关于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呢？