DAO与SERVICE层的疑惑

    一直以来都是开发EJB的项目，对于SSH的架构仅仅只是处于了解而没实际开发过，最近正在将公司的一个EJB项目重构成一个SSH的架构，在实际开发过程中遇到了一些问题，其中一个就是持久层和业务层之间数据传输的问题。

    在原来EJB项目中，都是使用实体BEAN进行数据持久的，而现在换成了DAO负责持久逻辑，一开始的时候业务层和持久层之间数据通信都是直接使用POJO进行，不再需要像以前使用EJB那样将DTO的数据set到实体BEAN上，减少了很多不必要的代码，刚开始的时候觉得挺爽，可是后来发现一个问题，那就是在service层调用DAO持久一个POJO后，POJO将变成PO，DAO持久方法将会返回一个对象，而我目前的做法就是直接返回一个PO到业务层，可是现在发现这种做法存在不恰当的地方，那就是PO在业务层的话，结果就将业务层与持久层相耦合，而DAO层的作用也因此而消弱，但是如果我不是直接返回PO的话，那我又要构造一个VO返回给业务层，那这种做法不是又回到原来EJB的方式上？而且这样我也无法在业务层上获得HIBERNATE很多优化性能功能，例如lazy load等，看了很多相关的帖子，但是好像都没有我想要的答案，请教一下我该如何解决这个问题？

仔细想想，如果想在业务层使用hibernate的一些特性的话，好像这种耦合也是必要的哦，不知道其他人是怎么做的。

很多人提倡OPEN SESSION IN VIEW，如果是这样，那不是在view层也要耦合与持久相关的逻辑？真是有点越想越混乱的感觉。

没人回答我的问题么？是我写的不清楚还是太浅了？自己顶下吧。

感觉具体技术还是应该跟需求走，是否需要有没有“状态”也要看你的功能有没有这个要求

仔细考虑了一下，还是一个对象通到底，service和DAO层都是PO，到前台就脱管成POJO，简单点好。

这个问题一直困绕我很久，目前为止，我也是没有找到好的解决方案

我觉得你在这里的说法有一些问题，我个人认为关于hibeinate这个框架，它解决的问题是使程序员摆脱原先的面向的关系的SQL语句的写法，使用java的面向对象的写法，使程序员在写代码的时候更加的方便，但是你却把它用来优化业务逻辑层，是不是与他的设计初衷有些违背。你是不是应该从这些方面考虑一下。

按面向对象的思想来说，并不存在你说的“PO在业务层的话，结果就将业务层与持久层相耦合，而DAO层的作用也因此而消弱”。
使用open session inview，把事务从dao层扩大到了业务层，在业务层po虽然可以访问持久层，但这是透明的，并没有对你的业务层代码有什么侵蚀。如果不用hibernate，用其他持久化技术，这个po将会是一个完整的对象。整个业务层接口和代码不会有什么改变。

我并不是用hibernate来优化业务逻辑层，只是我在用到hibernate的时候，我必然要考虑性能这方面的因素，hibernate是ORM，但不代表不考虑它的性能，你这种说法有点过于偏激。



使用open session in view不是把事务扩大到业务层，而是扩大到了表现层，这中间存在的问题就不多说了，还有从代码上来看确实是没有依赖于hibernate的地方，但是实际上还是依赖了，举个例子，一个update的方法，在业务层直接通过session缓存load到一个对象，然后通过set方法把值改变，因为缓存于session，我们不需要在最后加多一个dao.update(obj);就可以自动保存，这段代码在hibernate行得通，可是如果DAO实现用JDBC或者其他的框架实现呢？我们就要在那些没有这一特性或者有这一特性但是方式不一样的实现上改动业务层的代码，虽然代码上来看是透明的，但是实际还是会有依赖，这种依赖我自己称之为透明依赖，因为透明，也比较难察觉到。

    不过这个问题在现在来说也不是什么太大的问题，我还是认为最重要不要太过复杂，能简单就尽量简单明了，层次分明就好。太过于在意反而会导致过度设计，带来不必要的复杂性，简单就是美，呵呵。