spring+hibernate中公共DAO的抽象问题。

可是看看你做的这个公共DAO，它到底做了什么呢？我不认为它比HibernateTemplate带来了更多的东西，分明就只是在外面加了一层自欺欺人的壳子而已。拿着这样一个东西，难道就能做出内容丰富的DAO并且又不被绑定在Hibernate？我表示深切的怀疑。

也许是我理解有问题，那么大家都在说的使用DAO模式来隐藏数据访问细节究竟是什么意思呢？HQL不算是绑定到Hibernate吗？

我希望是能够让大多数的访问都能不通过写HQL来实现，做一些基础的操作，如根据某个属性排序，分页等等能够直接有那么一个接口（当然，在我的那个实现里没有提供接口，只是为了试验而已），我发上来是希望有人能够给我些批评，让我能知道我是不是在犯错误，可是好像连开口骂的人都没有，难道没有人愿意浪费这力气?

不绑定到Hibernate这个问题我倒是考虑过，如果提供一个完整的BaseDAO接口呢？我不知道你有什么好办法？

再多问一句：如果要做DAO层的话，你认为怎样使用Hibernate做DAO层才正确呢？

如果注意观察业务层访问DAO。可以发现两类模式：
一类为更新PO，另一类为查找PO。
并且更新PO的方式，完全一样，但是查找PO的方式则各不相同。
这样，如果想抽象公共DAO。那么也只有更新PO的方法可以考虑。
假如想得到一个含义明确的查找PO接口，那么无论如何是偷懒不了的。
这时可以考虑按查询特定PO的方法来划分接口。

另外，将业务逻辑同DAO混淆在一起，并不是一个好的方式。业务逻辑同
DAO需要考虑的问题域不同。

通过在业务层中定义DAO的接口，可以使得不同的问题域得到分解。

我想你没有明白我的意思，我的意思是BaseDAO可以有，只是它永远不该被暴露给业务逻辑。也就是说，业务逻辑的代码永远不能直接使用BaseDAO，只能使用继承BaseDAO的接口。

这样的设计我认为纯粹为了减少DAO内的函数的数量，例如，在继承的DAO中就不需要再写saveXXX，updateXXX了。其他的好处，我还没有想到。

同时，如果要写BaseDAO，我觉得load操作越少越好，为什么要那么多让人感觉一点也不common的复杂查询在一个基类里面呢？

看了这段反而晕了
简单的说
你的意思使把BaseDAO做成抽象类，然后由XXXDAO来继承它以减少XXXDAO中的方法
是吧？

差不多就是这个意思，不过我不认为需要abstract。

其实我所强调得是：如果需要一个DAO基类，这个基类是不该暴露给业务逻辑层的

这个大家都是这么想的吧，其实在改Hibernate Sync的模版的时候，我就在想是否把BaseDAO做成XXXDAO的私有变量，这样继承变成组合关系
不过最后还是做成抽象类了

我感觉不是很好，现在这个项目我已经全部手写XML并且使用Spring提供的一些事务性支持。Dao变得很薄了

那说明你做的case只是你自己玩用的，或者一个不需要太多数据访问的application，说明你的应用数据量少，数据库结构简单，那并不是企业级应用。既然不是企业级应用，谈封装，谈层次，就多余了吧。

BaseDao我觉得封装简单的CRUD操作就成了，目的是減少一些代码量而已，象这样

public User getUser(Long id); {
    User user = (User);super.get(User.class, id);;
}

只是简单的调用基类的方法再转型的就大可放到service那层去就行了。
另外我现在倒不太喜欢象JERT中把DAO,Service合并成一层的实现了，因为那样我很难再隔离开数据庫访问的代码对我的业务逻揖进行单元测试。