讨论：多层架构中是不是绝对不能把PO传递到表现层？

这个帖子还在讨论呀？

    呵呵，任何数据都是要到数据库的（不过这种说法好像也不对），作为一个做UI的人，根本不应该去关心数据的存储（究竟是文件、数据库或者网络其他存储形式如邮件等），这就是一个大型系统所需要采取的。如果只是一个桌面的系统，自然没有必要那么麻烦。
   内存的开销，对象的赋值的确会增大（这个我毫不避讳，甚至希望找到一个更好的方法），但是在基于网络的大型系统中，这根本不是重要的问题，系统的性能根本不会因为它而明显降低。（在考虑优化性能的时候，首要解决的是性能的瓶颈。）

    所谓的分离其实就是封装，封装是分为过程封装和数据封装的。所说的过程封装其实也就是处理逻辑封装，而数据封装也就是信息的封装。
   就如同在处理OOP的时候一样，如果一个对象内的数据被外部任意的使用和耦合，那么也就违反了最为简单的开闭原则。
   架构的设计、框架的设计与类的设计，都是OO的体现，只是范围不同罢了，思想都是一致的。（也就是由A到D到P）

凰兄说的不错，不过这和PO整个对象在各个层次出现并不矛盾。PO的属性肯定不会是public的。如果一个对象的数据不能被外部所用，又有何意义呢？如果用另外一个对象来间接地使用这个对象的数据又有何益处呢？这样的分离给我们带来什么好处呢？难道仅仅为了隔离而隔离？我觉得隔离主要还是针对各个层次的逻辑而非数据。

      会影响的，特别是在查询的时候。（在给出少量条件：即数据库的中的绝大部分数据满足条件）
      因为hibernate的影射机制，当对象之间的关联超过3级或4级的时候，
我们在客户端在得到EJB的远程接口后再调用查询业务时（提交查询请求），然后那种等待的时间就够你受的了，还有就是返回的数据集的庞大。并且 如果数据库的数量特别的大，象人口数据等，及有可能会让EJB的会话超时 导致查询失败。。


我比较赞同这个说法，同时我现在还没有体会出：


我知道 我们现在谈论的是经验之谈，经验 为的就是让后来的程序员不要再在同样的问题上犯类似的错误，为的是让后来的程序员可以站在前辈的基础上做出更好的开发，做出更优秀的软件。。。

所以我真的没有感觉到这样分离的好处。在做项目的时候，分离和不分离都使  我就亲身感受到任何详细设计的变更都会导致大量代码的变更，让人很狼狈，总是让人在改代码上绕圈。

补充：我新手上路，我真是毫无经验之谈
上面说谈经验，其实是我在借鉴你们所说的经验，我感受到你们的思想 使我真的一天一天的提高，所以，真的非常感谢你们

[quote="menghuanlang   会影响的，特别是在查询的时候。（在给出少量条件：即数据库的中的绝大部分数据满足条件）
      因为hibernate的影射机制，当对象之间的关联超过3级或4级的时候，
我们在客户端在得到EJB的远程接口后再调用查询业务时（提交查询请求），然后那种等待的时间就够你受的了，还有就是返回的数据集的庞大。并且 如果数据库的数量特别的大，象人口数据等，及有可能会让EJB的会话超时 导致查询失败。。


   哈哈，四五级的链接查询，你居然用hibernate实现，真够BT的了，呵呵，难道HQL可以代替SQL？？？
  如果是多对多关系，如果是多级链接，建议你还是用视图，然后再视图映射吧！这个性能的损失是你在设计上就出现了错误，而不是说对象赋值怎么样，将1万个PO对象赋值给VO对象，也就是一百多毫秒的事情，比较网络7，8秒要求的响应还用得着去考虑么？

就查询而言，我总是觉得用o/r mapping来实现，在有些地方有些别扭，例如上面说的四五级的关联。

我觉得四五级关联的时候，要么写view来映射，要么从session拿到connection直接执行sql，应该都是解决的办法。

哈哈，，浩哥你太厉害了，可以讨论这么长时间，真佩服你们！

我看到有点晕，，，

但我喜欢看！收获很大！嘻嘻，，，，，，，

唉，顾着做事，居然没赶上这个帖子，亏大啦