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

Agree, "Code Is The King".
你可以看一下这个open source的项目，我是用一个Object串起来的：
http://quake.3322.org/confluence/display/SOA

CVS check out 信息：
http://quake.3322.org/confluence/pages/viewpage.action?pageId=144

你可以看看这样做有什么样的问题，欢迎意见和反馈。

javeeye竟有这种夜郎自大的家伙，呵呵，林子大了什么鸟都有啊。
建议roobin清理一下门户，给论坛一个清静的讨论氛围，不要让某个苍蝇嗡嗡嗡嗡乱飞，我打我打。

好端端的讨论技术，不要弄到人参攻击上。pufan我先给你个口头警告，以后这种帖子我看到可就要喀嚓了。

看清楚先，是谁先人身攻击的。

看到这篇帖子，让我想起了金庸的《笑傲江湖》中华山派内的剑宗和气宗之争。

严格的分层像是所谓正宗的气宗，以先练气为主；直接将PO传至界面，像是所谓歪道的剑宗，以练剑为主；当然最终那种方式好，我就不说了。

其实，只要能够将敌人击倒，练气和练剑又有何分别呢？只要能成功的将产品或项目完成，是否严格的分层或传递PO，又有何关系呢？

只要能抓住老鼠就是好猫，我觉得还是简单实用有效就好。

让我选的话，我会将PO传递到表现层。

分层和传递po不冲突的。
分层的作用在于明确职责，相隔的层之间是彼此透明的，而作为现实世界的抽象的po（暂且叫po）是独立于层次、位于各层之上的。换句话说po是从属于系统的，并不从属于各个层次。
也就是说练剑也好练气也罢，谁又说不能同时练了。

我個人的看法
直接把po傳到view，使用的方便性是狠明顯的，但是會造成過分使用pojo的威力，也很難抵制這種誘惑，就象使用jsp一樣，jsp威力很強大，但為什麼mvc提倡只用jsp做表示就夠了不要在那裡放業務邏輯，因為pojo並不象表面上看到的那麼簡單，
如果是open　session　in　view，那麼對pojo的setter會觸發uptate，這就不是view應該做的，
用vo或dto可以很好的限制這種威力，耦合將大為減弱，
如果你要在view使用pojo的威力，那麼將和hibernate捆死。
但是使用dto，增加代碼量和部分性能損失是不可避免的（使用hibernate作為持久層），還有對關系的處理不好控制，容易發生巢狀鏈式反應，好處是層和層之間只通過一類對象聯系，並且只和一個層發生直接關系，
view--[dto]-->service--[pojo]-->persistent.
如果是團隊開發分工明細，這樣分層的好處是，可以把工作分開互相影響程度會有效減弱，負責view的不用關心hibernate的使用，因為view操作的永遠是service和dto，persistent層的不用擔心pojo會被誤用，service只關心業務邏輯，提供適當的接口給view使用。
但是如果從view－service－－persistent都是你1個人搞定並且要求快速開發，以後代碼的維護也是你1個人，那麼把po傳到view的確是方便，代碼量也明顯下降，這樣的話我認為可以考慮直接的用jsp來的快不用mvc了。
以上是我個人對各大牛的高見和自己經驗的理解不對的地方請大家拍磚。
希望大家和心順氣的討論，目的都是一個找到更合適和恰當的解決方法。
雖然少量的過激言語會加熱討論氣氛，但是容易引發過分使用它的威力引發大面積走題。

然也。我的问题：多层架构中是不是绝对不能把PO传递到表现层？ 本身就承认了分层的概念。

btw，再说一遍，讨论技术就是讨论技术，不要互相人参攻击。人家说你MVC，TMD白理解了，丝毫不去思考什么的，不要怒，你知道自己没有白理解，知道自己思考过了，你有自己的底气，又何必证明给别人去看呢？置之一笑就行了。

Open your mind, focus the point, that's it.

大家还是平心的讨论问题吧。

我觉得大家有点个扯个的，
xanada的观点是po是否需要 绝对 不能传递到表示层，如果凤舞凰扬表示反对，那么观点应该是：
“po绝对不能传递到表示层”，不论什么场合。

观点总是于自己的开发经历相关，轻型开发多的，倾向于直接传递po，而开发大型系统的常使用ejb的人，倾向于分离。我属于前者，我传递po.getClone()。

说绝对有点偏激，凤凰兄，或许你说的是对的，
但也可以先简单的传递po到表示层，等vo复杂了在考虑重构也是可以的，或者等我们吃了直接传po的亏，在重新做人也是可以的。：）

几个名词：
po －－》persisted object 持久化对象 位于持久层（hibernate）
eo（暂且起名叫eo） －－》entity object 实体对象 位于个层之上，真实世界的抽象

论证范围：对象建模（非数据建模）
论点：多层架构中完全可以把PO传递到表现层，甚至还可以把po从表现层传回到持久层，po是跨层次存在的，不存在任何的耦合问题。

论证：
对象建模是不关心持久层的实现的，只关心eo的抽象是否正确、eo之间的关系是继承、关联、聚合还是合成。持久层对于我们来说只是eo的存放地而已，至于用什么存放（hibernate也好jdbc也罢 ），存放到什么地方（数据库也好文件也罢），甚至不用存储（内存数据库Prevayler ），这都不属于对象建模关心的范畴。

eo是跨层次存在，是独立于个层之上的。eo的本质就是外部世界的抽象，这种抽象应该贯穿于系统之中，不管是表现层也好，业务层也好，其中使用eo、存在eo是我们对oo设计的理解。实体就是实体，相对客观存在稳定的情况下实体是不变的，没有必要分别存在它的副本、镜像。

po（eo）可以跨层次存在的，不存在任何的耦合问题。当用hibernate做持久层实现，po在结构和概念上和eo是那么的相似，于是就产生了用po代替eo的做法，但此时的po在本质上还是eo，只不过是在持久层中存在而已，po传出持久层就变成了eo。

总而言之，要oo就oo到底，不要被什么所谓的模式教条勒住手脚。谁说的了，剑法的最高境界在于无招，无招胜有招也。


不是view應該做的就不要做好了，可以规定view只能get，不能set，set可以交给contrl层或业务层去做。


po就是eo，怎么会捆死那，lazyloading的po只是代理不影响eo的使用。我不用hibernate也一样用eo，eo是独立于个层之外的，这和持久层用什么实现没关系。