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

目前的J2EE架构中，大多都有DAO层，在我们的项目实践中也是这样，而且由于使用了Hibernate或者Ibatis这样的持久层框架，把SQL都放在了外部的XML文件中，由一个ID来引用。
现在的问题是，大多数的情况下，在DAO中我们只是简单传参数，然后运行指定ID的SQL/HQL,所以有同仁提出，建立一个单一的DAO类，封装了基本的操作，然后在Service层都引用这个DAO，直接传SQL-ID和查询参数，就不用写那么多DAO类了，可我觉得这样就不是一个DAO层了，退化为一个类似工具类的东西，所以放在这里大家讨论一下，此方式有何优缺点或不妥的地方。

层的意思是必须要有很多类吗？？？



建立一个单一的DAO类，封装了基本的操作，然后在Service层都引用这个DAO

我们就是这样的

难道还要专门为每一个SERVICE写一个DAO？

CRUD中最麻烦的是查询。每个对象都有一大堆查询方法，千奇百怪五花八门。所以现在的Dao膨胀得很厉害。加上很多人不能理清楚Service和Dao的关系，Action里都是HQL。
所以如何在隔绝具体实现的情况下零花灵活查询才是问题所在。希望JPA2能够给出一些更好的解决办法。虽然Hibernate和Jpa中也可以使用命名查询。但是很多时候查询参数是不定的。比如查一个对象的创建时间在某个起始时间到某个结束时间之间。这是一个很常见的情况。但是这其实是三个查询，一个是只有开始时间、一个只有结束时间还有就是两个都有。命名查询就需要3个。推论到所有的对象上，命名查询会疯长的。

既然用JAVA，那么查数据库，不管你多少参数还是得放DAO吧。

一般CRUD放一个DAO，千奇百怪的条件查询另放一个DAO。

使用1个共通的DAO当然最好，因为这样会为你省去非常多的类，而那些类里的逻辑往往差不多。当然是用共通的DAO你需要对结果转型，转成你需要的bean，但这也比写那么多DAO强多了，或者你可以让结果的类型变为Map，那样更适合共通化。你可以放下包袱，只关注你的业务逻辑。

通用的增，删，改可以用一个通用的dao，甚至基本的查询都可以放这个dao里；但查询的方式有很多种，不可能一个dao完成所有的查询业务的。
如果不需要那么多查询业务一个DAO就足够了。

如果真能只用一个dao解决，那么祝贺你，你得到了一个虚拟数据层(高度抽象的数据接口)。这是一个比dao更高级的存在...

如果很多DAO可以合并成一个，说明其变化性不大，那就应该合并成一个。如果一个DAO总在变，一天一个版本，那么最好把易变化的那部分分割出来单独维护

这么说，是不是意味着用继承呢？