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

xanada

大家都知道，PO是不被提倡直接送到表现层的，因为这样做
1.不能降低层次间的耦合度，不利于以后的维护。
2.在lazyloading的时候可能还取不到数据。

所以通常我们的做法是这样的：

jbaggio

Quake Wang

我是把PO传递到显示层的，不使用DTO，减少不必要的麻烦。

http://www.hibernate.org/hib_docs/online/atljug04_presentation/hibernate_atljug2004.pdf
里面有提到 DTOs are Evil 和 Detached Object Support

Lazyload的问题可以通过open session in view解决，或者准备好完整的数据以后才交给显示层展现。

凤舞凰扬

看到这样的问题楼上的几位兄弟还在讨论，实在有些遗憾。我曾经在关于这样问题讨论上发了多个帖子，可惜，大家都不怎么看，看了也不怎么思考。
PO是什么？难道就是hibernate中间才有？如果是讨论具体的一样东西，我也须不会回帖了，但是看到大家把架构都抬出来，但是一些基本的概念都不清晰的时候，我想我应该回帖的。
没有hibernate是否有PO？当然！CMP、BMP、JDO都是PO，甚至你自己都可以写一个，只要这个对象具有持久性，就是PO。我想问问楼上几位，CMP、BMP可以传递到表现层么？
你们所谓的传递到表现层的对象已经不是PO，而是VO了，因为它根本不具备任何持久性，只是一些数据的对象封装罢了。VO又是什么？它和PO有什么关系？PO反映的是数据库实体的存储，而VO是反映的是业务逻辑或者表现逻辑的一种对象（或者又称为DTO吧）。一个VO可以小于一个PO（比如说我们查询的列表，就只会显示少许的字段）；一个VO可以大于一个PO（简单地将，就是一个数据库视图级的反映）；一个VO可以完全和一个PO相同（也就是楼上出现的现象了）。
如果自己实现PO，那么的话，我们的确可以用一个对象起PO和VO的双层作用，但是我可以说，这是极其低劣的设计。为什么？简单地讲，它给我们带来这样几个问题：一、所有的表现与数据库的存储完全挂钩，既然这样，就不要谈什么架构了，谈架构就是笑话。二、系统间完全耦合，没有任何层次可言，任何一个地方的修改会导致整个系统的修改。三、当需要一个VO大于PO的情况（我们知道数据库许多表中存储的是相应其他表的外键，而不是具体的值），这个时候，就会出现数据装载的问题（要么采用延迟装载，要么一次性大装载），极端地讲，一个业务实体如果引用了十多个基础实体，那么在显示业务实体的时候，就必须访问十多次数据库，要么就是一次性十几个实体全部装载，两者就是速度、内存的极端反映。
说了这么多，我希望楼上的兄弟在讨论架构这样大型的概念的时候，要充分地想一想。批判精神要有，但是前提是你真得理解了～～～～～～～
希望这样的帖子，对你们有益～～～～～～。

yangzheng · Apache Tomcat 加入时间: 2004/04/04 文章: 7 ￥: 85

关键是楼主没有做过这方面的项目，如果在项目中采用“PO传递到表现层”就会吃到苦头。
我已经吃过这方面的苦了。 Sad

lizwjiang

我就是怕吃苦頭﹐所以就統一的把po在action層轉換成vo,我現在用的是struts+hibernate﹐所以一直注意這方面的東西﹐也開貼討論過﹐但是大家好象道理說了一大堆﹐但是沒有把具體的東西分享出來﹐我很不想看到有人說﹐具體問題具體對待﹐個人有個人的情況﹐那么能不能把你個人的情況說出來﹐在hibernate問題解答版﹐我發了一個關于struts+hibernate的架構設計﹐被斑竹加為精華﹐現在看來﹐真的汗顏。。。﹐寫的很爛﹐真的希望不會誤導大家。

动物园的猪 · Apache Tomcat 加入时间: 2004/03/18 文章: 6 ￥: 145

xanada

To: 凤舞凰扬

其实我想讨论的是：多层架构中是不是绝对不能把PO传递到表现层？举一个最简单的例子，一个VO可以完全和一个PO相同。这种情况下，又为什么不能把PO传递到表现层呢？所以说，批判精神要有，但是前提是你真得理解了别人在讲什么～～～～～～～ Smile

那么有人又会说，这是极其低劣的设计，因为架构，耦合blablabla，其实这才是我想要说的：不要为架构而架构，为耦合而耦合，你真的明白你需要的是什么吗？你知道什么是YAGNI principle吗？面对一个概念清晰，层次臃肿的架构和一个实现优雅，层次简单的架构，你会选择哪个？

我会毫不犹豫的选择后者，而非前者。

凤舞凰扬

一个VO和PO相同,这当然可以,但是这并不意味着PO可以传到表现层,因为那根本就不叫PO了(我前面的帖子已经很明显地说了,你所谓的PO起了两个作用). 首先，我们明确我们是讨论什么问题，是问在实际中一个对象是否可以在各个层次生存还是问在架构设计中这样做是否恰当？如果，楼上只是谈一个对象是否可以在表现层、业务层、持久层都存在，当然是可以的，但是如果把它拿到概念层次，谈所谓的架构和框架，就不能这么说了。我不知道楼上是否懂了！
如果楼上讨论架构，把问题说这么大，我可以这么说，让一个对象从头到尾的使用100％是低劣的设计。我另外想说的是，低劣地设计并不是完成不了功能，只是它没有好的可维护性和可扩展性。
如果只是单纯解决某个问题，当然可以像楼上那么做，要知道，在必要的时候，连GOTO都可以，但是我们不能因此说明这样的设计是好的吧？楼上，你在考虑问题的时候，只是贪图某些局部的便利性，追求某种所谓的简洁，要知道，要真是所谓的简洁，就不需要架构设计师去思考设计架构了!

凤舞凰扬

我们在这里谈的绝对不是说一件事情绝对能怎么样或者不能怎么样，那样没有意义，不是么？比如说，我们强烈建议在程序的编码中不要使用goto，但是同样不意味着绝对，为什么？因为在很多领域（比如数值分析，图形绘制）都离不开它，并不是像有些人所谓的goto可以被三种基本过程（顺序，分支，循环）所代替就真能所代替的。
我只所以发这些帖子，不是针对任何一个人，但是我可以说，我是过来人，在我经历的最开始的时候，在使用petstore的架构的时候，我就碰到了诸多问题。经验是积累的，我愿意把我所积累的一些东西与大家共享，也愿意分享大家的经验，各自都少走弯路。
楼上你可以发起投票，我相信有三到五年以上经验100％是同意我的说法的，原因其实很简单。
一个好的程序员，个人的理解能力很重要，但是更加重要的是吸收。也许我的语气让你感到了排斥感，这倒没有什么，只是不希望你再走这样的弯路

xanada

我只是开个玩笑，说不上什么排斥感，你多心了。

其实你说的我都明白，但是你还是太拘泥于概念了，PO送到表示层就不是PO了，而是VO了(确切得说，是detached PO)。那又如何？你把它当VO用不就行了吗？我用绝对两个字是为了更醒目些，其实呢，大部分WEB应用，使用OpenSessionInView模式，都可以把PO直接传到表现层，而不需要DTO(不包括EJB)。

投票什么的就算了吧，建议你去透明的blog看看
有点开窍了

再去potian的blog看看
DTO，我需要吗？

Open your mind，就知道我说的有没有道理了。 Smile

凤舞凰扬

呵呵，楼上，如果是讨论一个具体的东西，我想你说的没有错。我不是拘于概念，只是你的表达会对很多刚刚入门的进行误导。
PO和VO是怎么来的？有什么区别？其实理解了这个，也就理解了问题的实质，PO只是数据库实体（或者说是物理数据模型）的一种对象反映，而VO是业务实体（或者说概念模型）的一种抽象反映。PO在属性上可以和VO相等么？当然是可以的啊。当一个业务实体可以用一个物理实体表示的时候，那么PO和VO在属性层次上其实就是一样的。
简单地讲吧，一个订单的业务实体，它包括货币，客户信息等，它就不能用一个业务实体所描述，那么，对应的VO是不同于PO的；而其中的货币信息，VO和PO在属性上完全就是一样，不存在其他的差别，这个时候，我们用和PO在属性上相同的java bean当然可以代替（注意，它不是什么PO，没有持久性，何来PO的概念）。
另外，我们如果不用VO，或者说不用反映业务实体的值对象，而用反映物理实体的对象，会带来什么呢？最大的问题就是会有三种：一、当一个业务实体需要多个物理实体反映的时候，客户端显示一个业务实体就会需要多次的数据库访问（简单地讲就是不用视图，而用多次单表访问）；二、当一个业务实体远小于一个物理实体的时候，同时需要一次性装载一定数量的时候，就会出现过多的数据垃圾与网络传输负载；三、当需要对后台物理存储或者物理实体进行改动的时候，必然就会影响到表示层，因为没有一个中间的过程将其隔离。
VO的出现目的是让客户（包括人和系统）了解的业务实体与后台实际存储的物理实体相隔离，降低各层之间的耦合性。其次，充分合理的提高系统的性能，降低调用的复杂度。
如果，看了我上面这些，楼上还是认为某些人提出的将实体从持久层传到表现层的话，我真是无话可说了。为了简单，采用JSP直接访问数据库更好。

凤舞凰扬

刚刚看来楼上留下的网址，看了那篇《DTO，我需要么》的文章。
其实，它符合了非程序员提出的软件以用为本。他强调了一个情况，“因此，我已经再也不愿意为了一个永远不可能分布的程序去实现这么一大堆DTO，结果就是我的代码减少到50%左右，我的所有代码可以非常简洁、OO的使用。”在一个项目周期短，经验不够，同时，后续的可维护性不高的时候，采用文中所说的也未尝不可。
我在这里想谈的，不是说这样简单小巧的系统是否改用繁杂的架构，那样没有什么意义。中国为什么缺乏好的架构设计师，因为中国太多的程序员只是将眼光聚焦在一个房间的装修或者一栋小楼的建造，而不去领会构造一个大型建筑的思维与境界；盲目地追求使用各种开源的工具与框架，什么地方都搬用，而不去领会工具与框架所蕴涵的思想的内涵与精髓与其带来的革命。
在讨论框架、架构这类问题的时候，我希望所交流所面对的，不应该只是一个普通程序员的出发角度。
软件以用为本，但不是以用则以。
我也许话说大了，我同样也只是这批人中的一个普通人，我也在努力地进行跳跃...............
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
刚刚写了一篇BLOG,有兴趣的朋友可以看看

pufan · JBoss 加入时间: 2004/03/03 文章: 45 ￥: 445

Quake Wang

PO，VO，DTO，分那么多xxO，只会增加Line Of Code，把系统复杂化，增加理解、维护系统的困难度，用Domain Object串起来就是最好的re-use。

关于多层架构中是否需要DTO来转化，hibernate官方论坛上在2月份的时候有过一个蛮长的讨论，有兴趣的大家可以用DTO做keyword去那里搜索一下。Gavin King也是不建议使用DTO，我前面提到的那个Link （ http://www.hibernate.org/hib_docs/online/atljug04_presentation/hibernate_atljug2004.pdf ），是他在1月份时的一个Presentation，提到了DTOs are evil，Hibernate的提供Detached Object 和 Version , UnSaved Value可以用来解决这方面的问题。