有关DAO的设计问题

本人接触三层结构开发时间不长，对于DAO方面有一些想法，也不知道对错，大家不妨讨论讨论。
按照我的理解，DAO介于持久层和业务逻辑层的中间，它的主要任务是封装对于数据库的基本操作（主要是四种基本操作）。对于现在，大家已经逐渐开始喜欢用Hibernate。DAO如果依然存在，那么它也应该封装数据库的基本操作。我曾经看了一些有关DAO的帖子，他们都提供了一些方法。但是就这些解决方案来看，我对此提出一些个人的见解和问题：
1、我曾经看见某位大侠对于数据库操作的封装的建议是：在业务逻辑层应该不含有任何的hibernate操作。我不知道这种说法是否正确，但是我觉得这应该是一种值得提倡的做法。在这种情况下，问题也就来了，如果在业务逻辑层不含有任何hibernate操作，那么类似于“模糊查找”或者说非常复杂的一些条件查询是不是就要放到DAO里面去了？这样的话，DAO不仅庞大，而且标准非常不明确，原本我认为DAO里面应该只有4种很基本的方法，但是如果加了这些复杂的操作，DAO就变得难以控制，因为我不知道业务逻辑需要我写什么样得DAO。
2、我目前写DAO的方法是这样的，我个人认为，DAO中的“增”、“删”、“改”三种操作对于每一个特定的表来说都是一致的。所以我把他们写成一个基类，这个基类的输入参数是Object类型的，对于每一个pojo类，直接调用这个基类的函数都能够顺利进行。至于“查”操作，由于我觉得查询的条件必须根据业务逻辑，所以对于查询操作，我是比较困惑的，不知道如何解决这个问题。
3、我在看很多其他人在写DAO的时候，并不考虑一些检验的情况。比如，我们往往会遇到一种情况：在往数据库里面插入一条记录的时候，主键是id（递增）永远不会重复，但是我们同样不希望有重复的名字name。一句简单的save语句应该是可以顺利插入数据库的，而并没有检验name的重复性。我的问题是，对于这些检验的操作，是由业务逻辑层的代码来完成，还是由DAO的操作来完成呢？
以上是我的一些问题和看法，希望大家踊跃批评，积极讨论。

一个好的DAO类层次应该基于接口，接口的设计特定于你的应用，比如一些模糊查询等等，你可以在接口上构造这种特殊的查询方法。
特定的实现在你的DAO实现类，请记住一点，如果你的客户需要这种查询，ok，那么就实现它，如果这只是你的考虑，ok,请去掉它。

spring framework 中validation被整合在controller在层

dao方法应该根据业务需要出发，但有一致的命名规则也非常重要，将crud将将抽象为接口或基类，这是通常的做法，但查询应该根据需求而定，一个传入where或sql语句的dao函数我想是需要避免的

to avoid? but i want 2 know how to solve it?

说实话，我个人觉得还不如传sql语句进去呢，至少DAO不用那么庞大，另外，我个人认为传入sql进去，至少DAO就可以于业务逻辑完全无关。按照楼上的写法，我是否可以认为：DAO是一个太不确定的东西，以至于开发业务逻辑的程序员和开发DAO的程序员必须事先协商接口？
我的主要问题是：为什么不采用接口统一？只有四个操作，“增”、“删”、“改”一致，“查”采用输入sql的办法？

我想过借鉴hibernat的criteria来构造查询，不过，那样感觉，要自己构造criterial和expression类，总感觉换汤不换药。

问一下，dhj1，你的DAO中的操作后，session关闭的语句注释掉了。请问，你打算什么时候关掉那个session？

DAO方面有没有什么比较正规的标准？我是指从DAO的实现模式（例如：工厂模式），DAO的实现方法的一套类似框架的标准？