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

我倒！
mvc是架构模式啊，还完全不相关呢，呵呵。
建议先把mvc搞懂再来这里讨论，不要浪费我们的时间和笔墨！

我建议，不要使用
“我倒，我晕”
“先回去搞清楚XXX”
之类的话。

没别的意思，发表一下真实感受而已。
你若真要建议，我提一个：
争论是好事，但前提是以理据争，让事实说话。
夜郎自大者不着边际、胡搅蛮缠这才是应该建议不要使用地。

MVC说来应该是称为一个框架模式

做什么事情都不可以拘泥，软件尤其如此。好都是相对的、具体的，
利用手头的技术和所要解决的问题更简单地解决问题才是好的体系结构。我随便说几点

1体系结构超越技术，但体系结构是和技术发展密切相关的，
例如，如果我们没有任何RPC的机制，那就不可能有分布式的结构。
这两者是相互促进的关系。

2 体系结构还和我们处理的问题有关，没有一种体系结构能够处理所有的问题，
或者说对所有的问题都是最好的（好像废话一样）。

所以如果你说A体系机构比B体系结构要好，那无疑是不恰当的。举个简单的例子，采用Blocking和非Blocking的I/O对服务器的体系结构会有很大的影响，
但你不能说Blocking比NonBlocking好，反之也不行。
因为如果你的服务器通常要处理成千上万的快速用户连接、关闭（譬如HTTP协议)，那当然是NonBlocking更能够伸缩了。
但如果你的程序通常是数百个长时间的用户连接，你观察到的结果将会正好相反。


3 体系结构的应用也不是绝对的、纯粹的，
实际上几乎任何复杂的应用程序不可能用一个纯粹的单一的体系结构来描述。
体系结构的选择要考虑到环境中的很多实际问题。例如微核心体系公认为在
很多方面超过单片结构，但目前绝大多数操作系统的内核还都式单片的。
因为操作系统不同组成部分之间的通讯会造成性能上的问题。
所以通常的做法是把最关键的部分（例如进程调度、内存分配等等）组合为一个单片结构形成比较大的核心，
而其它部分（例如文件系统）则可以不实现在这个核心内部，获得好处是可以动态支持多种文件系统，可以替换文件系统。

------------------------------------------------------------------------------------
其实越复杂的系统就越难使用DTO，有时候甚至我们宁可承担远程对象的开销都愿意直接把领域对象传输到界面上。

pufan，如果MVC叫做系统架构，倒的晕的不该是你，该是我了，我无话可说。你好好看看MVC 的书，好好理清楚它的来源吧。（它最早出现于smalltalk，比较成熟地运用于java的swing，一直到后来b/s的广泛应用，才将这样的思维或者说模式移植到web应用中。smalltalk是架构么？swing是架构么？）你倒是蛮想攻击我贬低我，不过前提，你得懂些概念，说些行话。
  Quake Wang，“在有了Hibernate，以及将来的JDO2和EJB3以后几乎完全可以抛弃。”这句话是你说的，不是我凭空虚造的。如果你说hibernate支持分布式，我想我不清楚，不该反对。如果你说hibernate支持分布式事务，那我很遗憾地告诉你，你应该没有弄清楚什么是分布式事务，在现有的大多数服务器中能够很好支持分布式事务的没有几个（有兴趣可以看看EJB编程指南这本书或者访问sybase的官方网站看看相关资料），更别说一个hibernate了。另外，程序的例子，要我怎么拿？（真拿出来，就该坐牢了），我已经很清晰地告诉各位了，如果有认识同望公司的朋友，可以问问他们，他们的系统也许到目前还是这样做的（这样够直接了吧，它不是一个具体的问题，不是一两个程序可以拿出来的，难不成要我把系统代码全拿出来不成，不现实啊！）
   potian ，“ 如果你说A体系机构比B体系结构要好，那无疑是不恰当的。”我们评价一个系统的架构好与不好当然不能是盲目的，也不是绝对的。但至少，它是有前提的。我前面说了，可扩展性、易维护性、高容错性就是表现系统架构的最为重要的指标，相反，性能,繁杂庞大，倒是其次（不要抓我小辫，不是说不重要）。
    我只所以反对楼主的这个提法，不是说绝对不行，也不是说我提的就是放之四海的真理。但是它只是一种策略，解决实际问题的策略，而不能被放到一个概念的高度。简单地举例，考试前大家猛复习一把，可以考一个不错的分数，但是我们在讨论针对学习针对考核的时候，把平日的复习看轻倒是把临阵磨枪看重吧？（不知我是否比喻恰当，各位是否理解我的意思）所以我说，如果楼主该个提法，我不反对，也许还赞成。
     最后，我只想说，我没有那么无趣，强迫大家接受我的观点。不过我想时间、事实能证明一切（至于其他的证明，因为诸多客观原因，我无法证明，并且，我个人觉得已经不需要去证明什么了），也许到那一天，大家会明白。我能说的，我经历过，我不会再犯回头的失误。

有人问struts+spring+hibernate是不是种架构，当然是。只不过架构不是那么简单。struts+spring+hibernate是用开源的框架构造快速开发模型的一个比较经典的结构，可以说是架构的一种体现。看过我前面的帖子的朋友都知道，架构＝框架＋框架间结构关系＋框架间通信（这个等式准确地说太简单了些，我只是想抓住几个重点）。不过，我另外想提醒各位朋友们，并不代表你用了struts+spring+hibernate就是好架构了，如果是这样，软件公司就不需要花上十几甚至几十万的年薪去聘请架构师了。
    想想，一个高级的系统设计师与架构师的差别在哪里？其实找出架构的特点及评价参数我们就知道了。一个好的程序员或者系统设计师也许能将别人做好的架构实现得很好，但是他无法从整体去析构一个软件系统，无法从一个个框架中剥离开来（所以很多刚入门的朋友非常喜欢追逐各种各种的技术，各种各样的框架，似乎越多越好），无法去根据架构的设计原则，根据实际的需要重构架构。
    如果各位朋友中，有人做系统设计的，想想吧，当你们的系统架构强耦合上述框架的时候，怎么对其他框架进行移植？当你在使用hibernate的时候，是否想过要使用ofbiz抑或其他？（一个项目一个框架，每次都重做，并非不行，但这样，公司为什么要请一个架构师那？）

这是我的原话，而不是只有你摘出来的半句：
对于Web应用而言，这种为了迁就JDO和CMP所做的削足适靴的设计，在有了Hibernate，以及将来的JDO2和EJB3以后几乎完全可以抛弃。

意思是有了Hibernate，有了JDO2，有了EJB3以后，就可以抛弃你说的这种多层架构采用DTO，VO的设计，而不是用Hibernate去抛弃JDO或者EJB。在对别人的论点反驳以前要先看完整地看完句子，这个是起码论坛道德，否则只会离题越来越远呀。

关于分布式事务，正如你说的是应用服务器的事情，Hibernate只要跑在支持分布式事务的应用服务器下，就可以支持了。再加上Spring提供的Transaction Manager抽象，你还可以几乎无缝地切换JTA Transaction Manager或者Hibernate Transaction Manager，你可以看一下文档， http://www.hibernate.org/110.html  。你说的Hibernate不支持分布式事务的论点依据是从哪里来的？我在Hibernate的网站上没有找到，你可以提供相关的link么？

我的观点是：在大多数情况下，多层架构应该由一种业务实体对象串起来（Domain Object），不能说因为目前JDO/CMP的限制做的切PO，DTO，VO的设计是合理的，这只是一种妥协而以。

凤舞凰扬:就象Alistair Cockburn 说一个项目一种方法一样，我的观点就是一个项目一种体系结构（混合）

至于扩展性、易维护性、高容错性是不是系统架构的最为重要的指标完全决定于你系统的目标，从前面的例子你可以看到，对操作系统而言，这不是的，对一个需要承受大量访问的HTTP服务器而言，这也不是的（你的机器在一定连接的时候已经崩溃了，哪来的可靠性）

再举一个我刚刚接手的项目来说，这个系统预期需要承受每天大约1000万-2000万次的访问，因此我们在设计的时候是让他生成静态页面，查询的时候通过搜索引擎，用户操作的那一层根本就是和数据库无关了（尽管后台100万个左右的用户还会使用传统的J2EE构架，使用数据库，其中还有即时消息系统）

至于系统的扩展性和可维护性并不是一蹴而就的（特别是不要去考虑那些到底需不需要的可扩展性，举个简单的例子，你用Hibernate花了1年作了一个复杂的系统，运行了3年，你真的会去换成ofbiz？），并且也是需要针对问题分析的，不是一个所谓的体系结构就能解决的，譬如这个DTO，很多方面造成了非常多的重复代码，是一个真正的反模式，只不过是我们无可奈何的选择。

体系结构是重要的，好比说软件过程是重要的，但不是一个可以泛泛而论的东西，针对帖子的这个题目，我想答案就是不是绝对的，说得更清楚一点就是：

在某些系统中，使用DTO可以提高系统的性能、可扩展性和可维护性，而在其他系统中，则是一种彻底的多余。至于使用的场合，我不单单在一个地方、一片帖子中提到过。关系到是否分布、领域模型是否复杂等等。

顺便说一下，一个程序员对系统、对编程的看法需要经历从简到繁，再从繁到简这样的无数次反复过程，当你不再需要一些名词、一些概念，当你偶然（不求每次）有庖丁解牛的感觉时，那才是真正的登堂入室之时。

首先，就“Quake Wang”给予致歉，的确是自己没有看清，呵呵，眼球往往抓重点去了，不过，这并不代表我赞成你的论断（谁说这种设计会被抛弃？原因是什么？）
   楼上portain兄，每天2000万－3000万次访问，您是做搜索引擎或者门户网站的吧？（估计新浪也不见得有这样的访问量）这肯定就不是系统了（而是静态页面），再说，这样的网站也必须是分布式镜像的。这和我们讨论的问题关系不大。至于一个项目一个架构，看怎么理解，如果是项目的规模差不多，而架构完全不同，基本上每一个大点的公司（比如100人以上）都有自己的架构，要知道一个项目组顶多就是十来个人，没有那么多经历重新设计和编写架构的。
   拿我现在的项目举例，我现在因为很多客观的因数，没有用hibernate，没有用Spring，也暂时不需要用MDB，不过这一切都要用，我可以很自然，不需要改任何东西嵌入hibernate，使用spring，使用EJB，使用真正的框架。我可以有需要的根据客户需求的实际情况对我的系统进行扩展补充和替换。在目前，连客户对需求都没有十足把握，所以对象的设计上有很大的出入，对于数据库的修改是必须的，那么对于我的架构来说，影响的不会太大，在不影响客户表示时，我甚至可以对我的数据持久层做全面的替换。想想你们的PO传递吧，能做到么？千万不要说我的少见（架构的设计就是有能力处理这种少见）