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

我现在做东西常常没有DAO，毕竟hibernate已经把数据存取简化到相当简单了。比如我最近做的一个东西，管理用户相关的信息就一个UserManagerHibernateImpl，看名字就知道是怎么回事：实现UserManager接口，继承HibernateDAOSupport类。这个类我还打算要换实现的，回头可能做一个UserManagerHessianImpl，我考虑做几个Template Method或者再加上一层DAO。如果是不太可能换实现，一定是走关系数据库，基本上这样就够用了。像楼主做的贫血DAO，我觉得还不如不要。

不同意Gigix把DAO做成那么薄的一层，DAO的目的就是隐藏数据访问细节不是吗？那么写HQL意义何在呢？

Spring+Hibernate的DAO的模板可以使用Hibernate Synchronizer来生成，如果对velocity比较熟悉的话（Hibernate Synchronizer是使用velocity来做模板的），可以自己修改一下Hibernate Synchronizer的模板文件来更改生成

不知道为什么这里的人都对Hibernate Synchronizer没什么兴趣，我觉得挺好用的，它基于模板的代码生成很方便，而且还能生成DAO，如果模板方法配置的好，DAO层几乎不用编码

我在这里发的更改Hibernate Synchronizer的模板来自动生成Spring+Hibernate的文章都没有人回：（

我现在做东西常常没有DAO，毕竟hibernate已经把数据存取简化到相当简单了。比如我最近做的一个东西，管理用户相关的信息就一个UserManagerHibernateImpl，看名字就知道是怎么回事：实现UserManager接口，继承HibernateDAOSupport类。这个类我还打算要换实现的，回头可能做一个UserManagerHessianImpl，我考虑做几个Template Method或者再加上一层DAO。如果是不太可能换实现，一定是走关系数据库，基本上这样就够用了。像楼主做的贫血DAO，我觉得还不如不要。

不同意Gigix把DAO做成那么薄的一层，DAO的目的就是隐藏数据访问细节不是吗？那么写HQL意义何在呢？

Spring+Hibernate的DAO的模板可以使用Hibernate Synchronizer来生成，如果对velocity比较熟悉的话（Hibernate Synchronizer是使用velocity来做模板的），可以自己修改一下Hibernate Synchronizer的模板文件来更改生成

如果数据访问的细节本身就很少，如果数据访问本身就不大可能变化，我当然可以把它融合在业务逻辑层里面。等真正出现变化了，需要封装数据访问了，再来重构出一个DAO层嘛。

另外，我不赞同代码生成，这常常为以后的程序调试带来不便。因为毕竟代码生成出来，你不可能一点也不做修改，有这点读代码的时间，早就自己写好了。另外就是代码生成限制了你的思路，万一你觉得某些地方可以去掉一个层次或者不需要它生成，还要去删除，累不累啊？

Hibernate Synchronizer 是我非常喜欢的插件，不过我不让她生成垃圾的dao,我宁愿实现一个通用的dao。我非常喜欢她生成po层次,她能够使得我非常方便的在po放入领域逻辑。我现在做ood时候从不考虑如何持久数据，也不会设计出什么xxxDao出来 用 Hibernate Synchronizer并不影响从对象设计出发的思维

如果数据访问的细节比较简单，我认为DAO和业务逻辑是可以放在一起的，毕竟事事无绝对。不是说一定要有DAO这样一个层次。

如果一定要将DAO作为一个层次，我赞同楼主的做法，不过不是完全赞同。我会写一些公用的操作作为一个BaseDAO，但是BaseDAO并不暴露给业务逻辑，而暴露给业务逻辑的是UserDAO，XXXDAO......这些DAO继承BaseDAO接口，这样至少可以简化DAO中的很多方法的数量。