DAO与SERVICE层的疑惑

我真的很欣赏你的简单就是美，其实我们使用的任何框架的最终的目的就是为了简化我们的设计，从而提高我们的效率。这个才是最终的目的。至于他的效率，当然也是我们设计的时候应该考虑的必要因素，但是如果hibernate的这个方面你认为不能满足你的要求的话可以考虑其他的技术或者手段。

1949说的好啊,虽然没看懂几句 ;) ,一些系统中的单dao其实很像是PersistanceManager,个人觉得最大的问题是struts1中的 actionForm.POJO才应该是领域中实际的对象

关于DAO SERVICE 一些个人看法
DAO层主要工作访问数据，有这了一层不用关心数据的来源,如果使用HIBERNATE，那么不用关心是直接连数据库，还是从一级缓存还是二级缓存中的数据。
SERVER个人认为是一些业务层的逻辑运算
使用SSH，如果有OPEN SESSION IN VIEW，如果基本是把PO与VO二个概念相对混淆了。特别是VIEW层直接把PO到表现层上去。使用了OPEN SESSION IN VIEW，读数据是根据页面展示所需自动从DAO中获取。对于开发企业业务功能，采用此模式已经足够了。但如果系统是一个超大容量的计算，如运营系统，这样的设计就可能有问题，即分层不清晰而引发各类问题，也不能很好的支持分布式计算。如果表现层就用VO，那么系统可以很好的解藕,因些把OPEN SESSION IN VIEW 去除掉，增加一层DTO，即SERVICE层有DTO的功能，当然这个DTO功能就是因业务需要VO到哪一层的问题，也就是控制对象粒度问题，大部分情况这些都是根据表现层来解定的。如果已有VO不能满足表现层展视的数据，那么在SERVICE层中的DTO就把PO2VO时，把需要的数据给VO。
个人在开发时在struts1时，DTO就要是把PO转成FORM BEAN,但做保存时，把form 转成 vo 通过hiberate session 接口持久成PO。当然当时的项目也主要是普通企业应用。
现在用struts2开发时（webwork），已把form bean概念去掉了，直接把实体bean”作为form bean"这样叫法可能让没有接触过struts2的struts1开发者能够更能理解struts2，因为vo/po都用同一个实体bean，因此通过OPEN SESSION IN VIEW,直接在页面把po数据在页面展示出来。或者把open session in view 不要，把service的po转成vo后在页面展示。

  嗯. 不错  这个思路清晰多了  是我明白了不少.

为什么不把所有的东西用接口去做呢，Java提倡使用接口进行操作。
你可以把你的Services只注入DAO的一个接口对象呀，同时在前台调用 的时候只要把Services的接口进行简单的注入就可以进行你想要操作啦。

没看太理清楚楼主写的东西，主要是写的太密集啦，多换几行看起来就能好点。

如果说你问的是层和层间的对象传递的话，dao层可以以返回值的情况给service，然后service里面可以使用ThreadLocal对象，把得到的东西传递到表现层，其实dao->service貌似也可以这样做，不过好象没啥必要哦

对于楼主说的lazy load的问题，可以使用open session in view的解决方案还是可以的，不过我也听有的人说干脆不关闭session,不过我认为这种方法不是很可取，毕竟等待自然释放不是一个很好的选择

For me,"domain objects" is a type of POJOs that only has data,almost no business logic. Another type of POJOs contains business logic,for example,"stateless beans" in EJB3 or Java Bean in Spring

这个方法不错!