只需要一个DAO，是个好主意吗？

看怎么用吧，像你业务中基本上就是curd那么是你这样做，肯定无妨！

这个无法避免的，业务复杂到一定程度，数据查询的多样性必然会导致不是方法多就是参数多，要不就是HQL多

你的dao不就是hibernate的session么，直接用好了，还封装啥。

直接用？session不是线程安全的！

用dao模式目的是为了解决action与hibernate的耦合。用DaoSerivice之类的是为了解决Dao与action的耦合。

如果你的需求长久的不会变动，你就是把你所有的业务逻辑放在一个过程都可以。


用一个Dao可以吗？我认为可以。如何应对未来需求变化呢？如：我写了一个生产单的Dao,原来用一个DAO能存储，

但是现在需求变化了，需要在生产单保存时，更新品检部的一张表，以通知品检部作好检测准备等。解决这样的需求

变化有很多种。其中有一种是：重新写一个特珠的dao,然后再关联action. 这要求先前，在action编写工作中，得到通

用dao时，增加一项任务：检查配置中有没有自已的dao,如果有就用自已特殊的dao,没有用通用dao.这个任务，可由父

action完成。子类，用父类得到dao的方法。这样，就能解开action与dao之间的耦合。如果类反射器用得好的话，就算

应用程序打包好了，也能在不改变原程序的情况下，只改变包外的配置文件，就能为action指定另外的dao。

其实我觉得IBATIS不就帮我们做了这个事情吗？
我们只要传入一个参数就好了~~~ 
    基本上直接在服务成调用dao。

继承也许是一个很好的方法哦

可以写一个公共的DAO实现方法------------》模块的Service方法调用。

我觉得还可以。dao一个就好，可以用泛型来实现通用化，Service层再细分吧

解耦，其实很傻很天真
我们竟然已经用了hibernate，非要把他和service层解耦，其实大家自己心里都明白，其实就是查询导致了dao的庞大
但是hibernate有很好的机制来方便大家灵活的查询，但是就是为了一点作用都没有的解耦，搞得一个service一个dao，有时候为了多一个查询条件，有多写了2个方法，dao部越来越庞大才奇怪，大家的项目真的都是那么庞大？没了dao就不能干活了?

适合的才是最好的~~~

其实都是千奇百怪查询惹的祸，ibatis还好，查询语句可以动态拼，hibernate我还不知道是否有这样的东西。把多余两个表关联的查询按模块独立出来。其他的增删改一个dao搞定