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

好长的帖子，终于看完了。感觉收获还是很大啊。
关于po,vo,dto的问题，看来还是得具体情况具体分析啊，我觉得对于那种用户需求不稳定，经常需要进行变更的系统，还是使用dto更好一点，而且po里面最好还是不要有getter,setter之外的操作，这是对客户负责，也是对开发人员负责。否则修改起来简直就是一场恶梦。

我们最近有个系统在数据库操作时用的是里面包含有数据库操作的一个entity类，然后在传到view层之前与actionForm进行转化，虽然没有直接传到view层，但是entity里面包含的操作与setter,getter混在一起再加上logger，导致一个entity类上到了5000行左右的代码，给修改和测试造成了很大的不便，客户检查代码是对那庞大的entity类也没什么好印象。

看了大家讨论了这么多忍不住出来说两句：首先大家张口分布式闭口分布式的，请问在场的分布式应用的做过的人有多少？反正我是没有，一般都是集群用的多。
   言归正传:先不管又没有数据库,不管分层，我们看看下面这件事该怎么做：
   例子：接受学生的选课单（selectClassForm），记录在案:
   流程如下
   确认学生的有效性
   确认老师的有效性
   老师是否开了这门课
   这门课这个学生是否有资格选（比如年级不对）
   都满足了记录下选课成功的这个事实

   现在再配上个网站 暂时不考虑数据库
   首先 selectClassForm 作为各在页面上的试图 单独对应一个 vo：formbean 大家没有意见吧
   接下来如何办：写在regsiterAction中

   0）college = new Colleger();;
    1);College.existSuchStudent(StudentID(););
   2);College.existSuchTeacher(sTeacherID(););
   3);teacherA =College.findTeacher（TeacherID();）
   4);teacherA.isOpenTheCourse(CourseID);;
   5);courseA =teacherA.getOpenedCours(CourseID);
   6);student =College.getStudent(StudentID(););
   7);student.CanBookTheCousrse（courseA）
   8）student.registered(course);  
   

   现在我们加上数据库:那会如何呢？
   college = new Colleger();---〉session.loadColloge() //假设有默认
    8）student.registered(course)--------〉session.save(student)
   剩下的都不用变 !为什么有hibernate的lazyLoad 在对象之间自由导航阿。
   前面讨论的vo po 还有什么eo其实vo很好理解就是用户想看到的视图，最不稳定的
   基本上是一个界面一个！在作业务对象（我把自己上面的对象称为业务对象）并不用
   去象界面是怎样的，对业务进行建模，建立以各对象图，和他们的业务接口。最后考虑实现
   数据库？前面很多人讨论什么dao说是要把取数据的分开好像和业务无关，其实不然：当我对
   选课老师说，“我就这么选了！”其实就是一个持久化的过程！
  
   最后我要谈谈dao，很多人在谈dao的时候总是说如果不用Hibernate的话，我还可以用jdbc代替，
   不依赖于具体的供应商，事实是这样么？你能用自行车代替飞机么？不可能阿，要替代只能在有相似功能的替代品上讨论。首先对对对象图的维护不是你用Jdbc随便谢谢就能模仿的，其实hibernate的session的接口就是个很好的dao包装一下就行了，不必没有业务对象都要有个DAO的。
  
   po 和 vo现在关系也就很明确了，完全是两码事，也各是model ,一个是视图，你硬是要拿出来给人看则呢没看个，立体的东西最多那个切面出来吧

hibernate + spring + webwork2 中, PO就是直接到表现层阿, 并且还用 OpenSessionInView 做 Lazy load, 感觉随着技术进化, 以前的有些理论也会慢慢演变的

PO=VO=dto=bo
当然有可能有独立的vo,dto,bo
po如果能直接用，就直接用，不会单独加一个vo,dto,bo
那样代码太不简洁

当然如果以后又一个强大框架自动去转换，那可以把这些对象绝对的分开来

我觉得xanada说得不错啊，要不然需要多少vo,vo到po的转换，po到vo的转换，代码臃肿，如果代码臃肿都是合理的话，那么vo=po一定就不合理呢，随着技术的进步，以前不合理的理论，到将来有可能就合理，就流行了，哈哈。不过，如果有ide,或者框架的支持vo到po的转换，po到vo的转换,倒是可以考虑。

在此不太同意凤舞凰扬的论点

一个系统的移植应用很多吗？比如你用了hibernate后，还会改成toplink吗，不太可能吧，就像一栋大厦盖好了后，很少有人把中间一层拆了重新盖

一口气看完了，所有帖子
意外的收获是从凤凰那里对架构和模式主键清晰了一点！

这个很老的帖子还在有人讨论啊～～～～～
   对于这个帖子，我想我们应该这样来看，我们讨论的究竟是什么，是种考虑问题和分析问题的思维或者说概念，还是针对某种实际问题处理的策略？就如同前面朋友举例，盖房子和盖狗屋一样。我们究竟讨论的是从建筑的角度改怎么样盖房子，还是说盖每个房子包括盖狗屋都得这么做？或者说盖狗屋就必须按照盖房子的方式？ 后者的讨论是没有任何意义的，因为软件只要能够很好运行就好。
   既然讨论架构，我们就必须从一个更高更抽象的角度去看待和分析问题了。
   有人说系统会移植么？多么？一般来说，具体的项目系统移植很少，也许永远不发生，但是那只是对某个系统的业务实现而言，而不是对系统的架构与框架而言。框架的移植是非常有可能的。就拿hibernate和toblink来说，如果你的公司做一个小价值，对安全性要求不高的系统，你会用商业的toplink么？而对于一个大型系统的客户，如果它只要求用大公司的商业组件，不准使用免费开源的，你会这么办？而这个大型商业组件是什么？toplink 还是EJB 还是JDO或者还是...，难道你公司的架构和框架要随之而变化？
   有朋友说VO没有必要，同PO一样，加一种反而冗余繁琐。的确可能如此啊。VO只是一种业务逻辑的表现，PO是数据存储逻辑的表现，VO完全可以只是一个PO的部分，也可能和PO完全相同，这样的情况下，去增加VO的确冗余。但是问题的关键是两个，一，VO也有可能由多个PO组成；二，谁能确定VO？
   相对于后台逻辑，VO是视图，PO是MODEL，而相对于客户表现，VO并不一定就是UI表现。因为业务逻辑所表达的信息是基于业务的，而UI的表现是基于客户要求的。这就是struts中的FormBean所担任的角色一样。
   当基于客户要求的表现（Form），基于业务要求的表现（VO），基于物理存储的表现（PO），还有贯穿于整个系统的业务实体概念的本身（BO）出现了某种一致的时候，混淆与混乱也就出现了。实际应用的简单，也许一个类，一个对象就涵盖了其中多个角色，多个概念。但是这并不代表没有这些概念与角色的存在。而这一切，又决定于实际的项目应用。

    今天是第二遍完整的看这个帖子，看了真难受，头晕脑胀的，就只有曹晓钢这句话能让我缓过来。
    大家讨论问题的时候这个气氛是好的，但是把这个帖子变成精华贴让后来者（特别是像我这样的新手）来看的时候，确实感觉到在javaeye讨论问题的时候一定要看清别人的论点，深思熟虑自己的观点。
   想到gigix一句话(记得不是很准确)：

想上论坛学到东西，真是异想天开。

真TMD正确。


还是这句话：为啥有人就是宁愿抠字眼也死不认错呢？

今天花了很多时间来细看此帖，首先楼上的说法不公平，大家花了这么长时间来争论，很多仙人都愿意以自己的真知来解释问题，这很好啊，即使偏离主题，即使有些呈口舌之快也无所谓，至少我学到了很多，体会到了很多，而且本来我相信javaeye为了保证发贴的质量，已经做了很多努力，我刚来不久，似乎看到回收站里已经牺牲很多贴了，所以呢才小心翼翼的在精华贴后跟贴以免再次发生跟的贴是回收站里的这种情况，哈哈，但这也是提高发言水平和语言严密性的一种苦修手段，我觉得要乐观一点的看待这个问题比较好，下面就发表一下我对此帖之感悟：
本贴的主角应该是xanda半仙和凤凰大仙，首先这两位仙人，老实说，一开始都有些极端，xanda走过的路可能没有凤凰走过的路来得长，正如楼上某楼层的兄弟所言，可能没有真正遇到po贯穿始终的苦难，所以呢，当一个人对自己的观点深信不疑并且试图强加于别人的时候，争论就开始了，这是人的某种劣根性所至，不过我发现sayor上仙的介入，使得凰仙似乎领悟到了自己是前辈，并且发表了很精彩的仙论企图将讨论从人身攻击转移到正题上，无奈后来有些仙友似乎仍然很喜欢硬咬某些无关的字眼，这个很逊我觉得，然而这样的回帖对于凰大仙来说，确不失为一件好事，因为凰大仙很较真啊，会拿出更抽象更精彩的架构仙论出来，要是换了我肯定估计也就笑笑了之了，这点我很佩服凤凰大仙，我觉得如果看过poeaa(patterns of enterprise app architcture),一定会对理解这个问题有很大帮助的，比如sayor说transaction script和domain modle以及domain object那篇，还有就是关于分层针对逻辑而不是针对数据的那篇，这是非常正确的，http://www.agiledata.org/essays/drivingForces.html,
至于oo狂人martin flower，我只有敬仰之情了，所以我觉得domain modle在注重架构分层的j2ee系统中是精确雅致的，而table module对于很多有高度审美情趣的专家来说，往往它只适合于.net之类的微软架构，由于微软对源码级数据以及本身基于操作系统级别的支持，所以当然也就屏蔽了很多j2ee系统中的结构问题，据rod johnson说，j2ee和.net是互相学习的,所以给出了spring之类的框架,好,扯远了,回过头看看现在的问题,po被传递到表现层也就意味着完全对client透明,如我上述所言,此时整个系统本质就是一个table module,如果你有足够的自信(dto<=po)并且保证client作为视图不会毫无理由的误操作po,那么这样没有问题,但当系统庞大到一定阶段了,你会没有自信的,相信这种不自信凤凰大仙肯定了解,比如某些需求的修改导致dto>po,某些开发者的妄为导致某个open session in view的正确应用成了edit table by session or by po(本人使用hibernate时间不长,可能对open session in view和lazy loading的hibernate做法还不甚了解,这里只是为了说明我的观点而猜测一下,如果有错还望指正),此时table module将不适合j2ee的系统,我们需要不仅仅为了逻辑,还要兼顾安全健壮而进行分层,不可否认分层即意味着引入了一个层级的复杂性,当然会有对象的创建和复制的开销,但对于复杂系统而言,那是可以忽略不计的,因为当你引入一个层以后,如果那是合理的话,那么这些开销一般不会是系统的瓶颈,除非当你发现某些地方确实需要优化,还有我觉得dto的本意是希望在网络分布式环境中，降低通信的开销，现在说dto是anti-pattern应该不是针对分布式环境而言，之所以说dto有成为anti-pattern的趋势，应该是指在不使用domain modle而使用类似controller-entity风格(poeea)的架构模式时的过度分层吧，
其实这其中隐含着一点，就是唆使我们必须打造出一个优良的oo domain model，此时dto就是多余的了，然而面对现在很多不同规模的企业应用，做到这点还是有难度的，由于dto依然可以工作并且有时候并不差，所以我觉得现在说dto是anti-pattern还为时过早，至少dto是一种符合大众思维的solution，另外有一点,我也有点不适,虽然凤舞凰扬说不企图误导开发者,但是无形中,你的确诱惑了我,因为很可能接下来的一秒中,我会着手把我以前的很多设计重构成可以适用各种架构的超级系统,我们做企业应用的毕竟有其局限性,就是不能很完美得去复用和移植企业场景或者说基于企业应用的企业架构,当然如果能做到而不惜成本，那也是另外一回事，如果你告诉我那是一个ide,我绝对要向你学习,因为那将会是国产的eclipse,呵呵,开个玩笑,但是我仍然很喜欢你,还有我忘记楼上哪位兄弟说的从简到繁,从繁到简的反复过程,这个论述我真的很赞同啊,我觉得我们都是这样的,最后希望大家真得去看看那本pooea,相信会对大家都有帮助的,如果你相信martin flower的布道的话