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

模式是方法（思维、分析、设计），是解决问题一套可以复用的方法。而架构是一种结构关系，完全不同的概念。sayor的帖子大家看看，MVC在web软件体系中可以看作是一种架构模式（也有人称它为分析模式或者设计模式），它只是web架构实现中的一种思维方式，一种解决方法。怎么好像连基本的意思都不能分清楚？（难道要查辞海？那真要晕了）
   简单地举例子：架构就是一栋楼房的结构（包括供电、给排水、防震、房屋框架构成，框架间的布置），模式是一种方案（比如防震，采用挖深的基脚或者采用什么样的材料搭配，当然，我这样比喻模式细节了点），这种方案是前人提供的，经过大家成熟运用的，能够快速解决架构问题的方案。
    模式可以跟任何东西搭配，包括设计模式（用来解决OOD的常用方法）、分析模式（用来解决OOA的常用方法）、架构模式（用来构建架构的一些常用方法），还有语法模式（用来解析语法规则的某些方法，编译原理中有）
    这样说了，还有人不明白么？唉，为一个这样的词眼都说上这么久，上google查一把，把架构和架构模式的概念搞懂吧！

我真是苦死了，本不想再发任何帖子，但是每次都忍不住来看，每次看了，又实在忍不住要发些帖子。
   有时我不是想太抓概念，但是如果最基本的概念都弄不清楚，就会说出很多比较令人费解的话来。要理解大师们的思想，你首先要理解它的概念，知道到底在说什么啊！
    如果有哪位朋友可以找到MVC is Achitecture，我立即闭嘴，像大家道歉～～～～～～～，如果找不到，就请不要再在这个问题上发言了，人都有些受不了了。

互相矛盾的观点。
我到想看看你怎么自圆其说。

呵呵，我看两位没必要再争论这个了，还是回到楼主的话题上吧。

不是我要争，这是个辩论态度的问题。
对别人的论点反驳的时候，态度要严谨，要对自己的言论负责，至少要看清楚别人的观点、Refactoring自己的反驳后再回帖。
你看错别人观点造成的不必要回帖不在少数了吧，你也不要说

是你的一时笔误，如果这样，谁还会相信你的下个观点是不是眼拙是不是笔误，谁又会对你的反驳再去回驳那。

你不负责任的回帖不是你的错，但耽误大家的时间就是你的不对了。

呵呵，我的话有那么难理解吗？我说了架构和MVC模式是相同的概念了吗？如果我说，这个人本质是好的。你是不是又要给我论证一下"人"和"好"根本是两个不相干的概念？可我本来也没说它们是相同的概念啊。

不审题就做作文是不好的

个人感觉,一般的hibernate应用的对象都是贫血的领域对象,以至于很多DTO和本身的domain没有太大的区别了,再加上有OGNL这样的东东,DTO至少看起来都是多余的.但是如果你的domain里面放置了逻辑,比如访问了持久之类的,如果还是简单的java对象(没有interface),直接拿到客户端也许就麻烦了.
在分布式调用中,客户端程序要编译通过就还得需要DAO之类本来应该屏蔽了类(没有远程接口了,只有引用实现),而且DAO之类的还变成远程对象(当然有接口也需要这样),当然有的地方还有严重的性能问题...
即使本地调用,由于没有facade, 比如事务边界可能需要在domain object的方法上划分了(spring这样的框架就麻烦了许多,当然不包括view中开session之类),而且假设没有接口,原始的动态代理AOP不行了,动态代理的mock也不行了...
如果此时增加facade,用DTO想客户端屏蔽你的rich domain model也许也可以,便于统一入口,也比较容易分工?如果不用DTO,domain object当包含大量逻辑时最好也增加接口?我感觉不加接口而又直接作为PO映射数据库的话恐怕仅在持久方面就很难屏蔽作到与具体逻辑无关.
上次看到potian提到OSUser,后来粗看了一下,我感觉,大家指的domain object一般就是PO(就是负责和数据库映射的类),那么domain object为什么就不能是DTO或者VO的位置呢?我也可以把DTO变成真正的领域模型(包含相关逻辑),暴露给客户端和service之类,而后面的PO负责映射数据库.当然这时的domain object肯定不具有DTO的性能好处.
如果domain object既作为PO,又作为VO是最省事的,但是如果domain又要包含大量逻辑,此时也许就麻烦了,也许不是spring和hibernate作者指望的方式.

架构和MVC从概念上本身就不是一个东西，只是基于用户界面的架构体系可以采用MVC的模式（也就是思想，要不是基于用户界面的，和MVC搭不上一点边），这就好比楼房的结构和对结构设计的一种思维，结构和思维是一种东西么?
   模式到底是什么？它是一种思维，一种解决问题的方式，MVC就是一种模式，一种解决用户界面表示问题的思维方式。思维方式是可以用在任何地方，分析、设计、实现，但是这不代表它和分析、设计、实现是同一个东西，我们可以把MVC看作一个解决基于web体系系统架构的常用模式（其实准确地说，架构远复杂于一个模式，MVC只是web体系架构中的一部分），这就代表MVC就是架构么？。一个是问题的表现，一个是解决问题的思维方法，这两样东西是同一个东西么？这样的说明，不知道还够不够清楚。
    我刚刚把所有的帖子都看了一下，之所以跑到架构和MVC上来，完全是pufan的一番言论。
    我之所以证明这么多，只是想表明这样几点：1.架构不仅仅是多层，也不是所谓的MVC，它复杂，所以讨论它要严格些，不能言必称罗马，动不动就是架构；2.架构和策略是两码事，架构应该严格，而策略可以根据情况变动（就像我前面帖子说的，一个把PO传到表现层的策略我不反对，也许支持，但架构设计成这样，我就反对了，其实也理解楼主最开始的意思也许就是策略，不过我怕文章会误导很多人，所以我反对，反对的不是具体做法，而是观点）；3.评价一个架构的优劣，体现在三个方面：可扩展性（也就是复用）、可维护性（容易修改和移植）、高容错性（可以调整和适用需求的变更），架构复用是软件复用的最高层次（所谓一个项目一个架构是应该改进的），而一个架构的复用起码原则是不能被其内部选择的框架或者组件所强制所约束。
    最后，说白了，我反对楼主提出的观点最主要的原因就是第三部分，因为这种观点严重的违背了它，它不能算是一个好架构。如果楼主的观点是策略，那么也就没有第三部分的冲突。
    现在焦点摆明了，谁对第三点有异议，可以提出来，我们另开一篇讨论。

我觉得domain object可以有一个接口或者父类，这个父类只有其属性和属性的getter,setter，对表现层仅作父类调用，在业务逻辑层中domain model继承该父类并扩展一些业务逻辑方法。在持久化层中，可以使用这些domain object作为PO，使用hibernate或者其他orm框架并不会有什么麻烦。因为数据库层不会来调用你的业务方法，因此不会带来什么麻烦。不知道ultra兄有何看法。

接口好一些，并应屏蔽主键的setter方法。其实控制view对domain object业务方法的调用口头规定即可，增加接口或基类会导致类数量的倍增，感觉得不偿失。
另对在domain object中增加delete,update等方法颇感迷惑，这应该是持久层的工作，难道这样做是为了reuse?