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

pufan 写道:

我這裡說的pojo的威力是利用setter觸發update等hibernate特有的特能。如果使用了，又環了持久層實現，那麼就要去額外的實現這些特能。

pufan 写道:

如果有個相應規則大家都遵守，並且在update和remove都采取先load再操作，pojo當做vo來用也是挺靈活的，

首先，sorry 一下，自己冲动了，说了句不该说的话，不过也难得有些朋友大量，不计较。
   我这里阐明两点：一，我的观点不是说绝对不能传递PO到表现层，一个很简单的应用，如同Pufun所说似乎永远不会改（不需要移植，不会有太大的变更）的情况时（比如小的项目、个人demo或者公共系统等什么），的确可以这么做，丝毫不要拘泥于某种限制（在适当的情况下，goto都可以用），这些都是对的。但是一点，在讨论架构这个词眼的时候，就不应该提出这样的观点了。前面的只是策略，但绝对不是架构。第二，我是经历过这样的项目开发的，不是像有些朋友说的我好像是空白谈书似的，如果有朋友知道的话，可以了解了解同望公司（交通行业最大的软件商）的系统，可以这么说，直到现在，他们也许还是这样做的。（我本不应该这么直接的说出，但是我只是想如果有同望的朋友，可以看看，可以总结），没有这样的经验，我何来如此反对？楼上有些朋友，我真敢说，你们绝大部分中做实际大项目的经验没有我丰富，我不是自吹什么，没有必要，现实中也见不了面。我只是希望我们能相互吸取知识和经验！
    我不想和任何人为敌，有人问我是什么鸟，呵呵，还算是个好鸟！
    最后，我给大家解释一下什么叫架构。架构（achitecture）来自于建筑学的概念，是框架（framework）和结构（structure）的合称。其中它与框架的区别主要体现在，它着重描述各个框架中的结构关系（之间的组合等），描述框架间的联系，突出它的结构特点。一个好的架构师或者设计人员必须对框架，框架的组合有非常清晰地认识。架构不会被框架中的组成所绑定所限制。软件系统的架构又体现在什么上面？也就是你所做系统所选择的框架，框架的组合，框架间的通信（包括协议、数据表示、接口联系等）。好，我结合楼主讨论的题目说说为什么不能在架构中表达这样的概念。首先一、用一种数据对象来维持多个不同框架间的数据联系，使所有框架相互绑定死，那么自然就根本没有体现出框架间联系的方式，根本就谈不上任何架构；二、楼主的PO来自于什么？hibernate还是其他，如果是hibernate，那么你的架构就限定于框架的选择（简单地讲就是一栋楼的设计限定于一层房子的结构），这还算架构设计么？如果是JDO、CMP，这样的PO还能不能传那？三、一个好的架构是怎么评估的，应该是可扩展、易维护，高容错，而不是所谓的一些性能的损失（它是放在后面的）。有些东西，看来的确不会出现，但是在架构设计中不能不考虑（就简单地如同，在非地震地区建的楼房依然要达到一定的防震等级），架构的设计，应该是就架构设计人员及相关业务人员的水平，充分评估系统存在的可能性。比如将数据库的更改（有人说数据库的更改是业务的更改，这是一个典型的错误，设计的更改往往是分析设计人员对需求把握挖掘不够），就会给楼主的选择方式带来灾难性的破坏，这样的非容错，难扩展的架构还能叫什么架构么？大家想想戴高乐机场给我们带来的启示吧（软件系统的灾难就是需要大投入大范围的重构）！
    我可以感觉得出，很多网友都是比较好的程序员，相信也能编出很高质的代码，但是，希望大家做到两点：从更高的角度看待问题，才能把握整体；不要动则就谈架构、框架之类的，爬得太高。
    楼主如果将题目改为“在实际应用中，是否可以根据需要将PO传到表现层”，那么我会明确地告诉楼主，这样做可以，根据实际情况也应该。但是如果再是讨论什么架构，拿出这样的命题，我只能说不能，甚至相当遗憾～
    我希望旁观者们，能够冷静地下来思考，想想双方讨论的焦点，讨论的理由，讨论的方向，更加希望，开卷有益，这样的讨论能够对大家起到帮助。

   接下来再就pufan的帖子回复说明一下。
  Entity Object是对象建模的概念，Persisetent Object是数据持久的表示，这两点都没有错。不过什么说什么PO(EO)可以跨层存在，实在就不苟同了。简单地问一句，CMP/BMP可以跨层存在么？JDO可以跨层存在么？这是一个很好的笑话，原因很简单，pufan对PO有了本质上的理解错误。如果PO只是一个普通的javabean,那么当然没有层之间的概念了，但是PO只是javabean么？要知道那只是PO的表现形式啊！另外，对象建模和我们讨论的这个是两个层面的东西，怎么被扯到一起做什么所谓的证明了？（PO只是物理数据建模的对象表示或者对象反映，和建模本身无关）最后，EO是外部业务的抽象，这个没有错，但是我们能把这个抽象直接给客户看么？既然客户用的都是抽象（客户OO水平高啊），那我们还做什么对象抽象？呵呵，这又是一个比较搞笑的观点了。
   看得出啊，所谓的无招胜有招，什么OO到底纯粹是搞笑的说法，能有那样的水平么？这样的下场只会是写出的代码耦合信极高，复用性极低（也许pufan编码水平不错，还能写出一些高质量的代码，但是先天的设计缺陷本身就制约了你啊）

1. 多层架构有那么神秘吗？其本质无非就是MVC，你叠的再多，也只是MVC而已(我理解的不对的地方请指正)。巨型应用是多层架构，三两个人做三两个月的东东就不能用多层架构这个词？

2. 所有的项目都要用EJB吗？如果EJB很好用的话，那干吗还有这么多轻量级的框架层出不穷呢？

3. 你的每个项目都是巨型应用？都要好几百人做好几年？如果不是，那么是不是还要抱残守缺的逮什么都先搭个大架子？

4. 不要有了一个锤子，就看什么都是钉子。

我前面已经强调过，在JDO1.0和CMP2.0，由于规范本身的限制，导致不能传递跨层PO，所以才不得不采用DTO, VO, PO这样繁琐，而且效率低下的设计。业界正是认识到了他们的缺陷，所以才会在JDO2.0 和 EJB 3.0规范中提出attach/detach support的要求。对于Web应用而言，这种为了迁就JDO和CMP所做的削足适靴的设计，在有了Hibernate，以及将来的JDO2和EJB3以后几乎完全可以抛弃。你可以去google一下近来关于JDO2和EJB3的一些讨论，会发现很多有用的信息。


简单的回答：基于有缺陷的JDO/CMP做的设计也是有缺陷的。不能说我的腿脚不便，需要拐杖辅助，那么看到没有用拐杖人的就觉得是可笑呀。

首先就xanada朋友的话给予说明，架构和MVC是两个完全不相关的概念，MVC是用来构建用户界面的一种思维，或者可以理解为一种模式，Struts以及各种web框架都是体现了这种思维，但是它和架构是两码事。我们可以说web框架是基于构建J2EE应用的重要组成部分（但并不一定，比如你可以用web service）。
   其次，就楼上的朋友说明一下，我不否认，在EJB2.0中的CMP以及JDO1.0的确存在这样的不足，同时hibernate也相当强大，但是如果说hibernate可以取代他们，那就是十足的有趣了，我想问问楼上，hibernate可以做集群么？hibernate可以支持分布式事务么？hibernate是什么？你们可以看看robbin的文章，它只是一个JDBC的轻量级封装（它最大的优势就是轻量级）。
    轻量级的东西能帮我们做什么？当然，它可以为我们解决不少问题，能够快速地构建一个系统和应用，但是说，在讨论一个架构这样词眼的时候，动不动就被这些框架这些组建所困促，觉得有些什么呢？难道大家做的系统就为hibernate而生？举一个有些不负责的例子：你们可以到JDON上看看，有篇文章是IBM的一位工程师留的，他说他们的系统开始准备用hibernate,但是客户要求IBM负责使用hibernate带来的问题，IBM不愿意承担，所以最终没有使用。任何一个框架都存在缺点，就连整个java one组织开发的EJB都存在，何况一个hibernate,把它吹成神一样，是否有些过了？哪个敢说它就没有一点问题？（我们要使用它，但是绝对不要依赖它）
    我不是动则谈大应用，动则就是大概念。但是首先我们谈的就是架构，比如建造，我们能对一个小楼房去谈它的架构建造么？多层，不是说，你描述一个多层就是多层了，不是说你简单地把程序分割开就是多层了，架构，不是说你把Struts+Spring+Hibernate拿来用就是架构了，不是说只是简简单单地结构关系就是架构了，他们仅仅是简单结构的一种堆砌。真要那么简单，个个都可以做架构设计师了。
    争了这么多，也应该结束了。我希望各位朋友站高一点，看远一点，当你们系统不依赖于任何一个数据持久层，发现hibernate好可以移植hibernate，发现EJB好可以移植EJB等等的时候，那么你可以对自己说，你的架构日趋成熟了。

纠正一下你的错误：

你可以看一下Hibernate的文档和代码，Hibernate是可以做集群的（限制：不能选择某几种id生成策略），Hibernate也是支持分布式事务的，它对于JTA的支持非常好。

然后是批评：

你为什么老是抛出一些大家更本没有提到的观点呢？我们在上面讨论中哪里有提到说目前的hibernate可以取代JDO/EJB？把自己臆想的说成是别人的观点，然后再批评一番，有什么意义呢？只会造成讨论偏离原来的主题。

最后是挑战：

如前面 动物园的猪 说的 “其实大家说得都好，从理论上讲，都有道理，只不过，缺乏代码的辅助，所以，我很希望看到你们在项目中的实践，'dont talk more, just give me the code'，呵呵。 ”。我前面已经列了一个用Spring + Hibernate的代码了，既然你认为Spring + Hibernate不算什么架构，那么你可以举个代码例子来说明你设计的better than Spring and Hibernate架构中，是怎么把分层和持久层无关性发挥得淋漓尽致的么？

呵呵，都退一步吧。
别就这个问题讨论下去了。我建议封贴～～～～～～

论坛不是欢迎这样热烈的讨论吗？我的观点是只要不离题，不人身攻击，就没有必要封贴呀。

封貼是一種沒辦法的辦法，
現在這一主題還沒有個正反方都相對滿意的共識，
我頁認為和封貼扯不上關系。