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

架构这个东西我觉得是牵一发而动全身的，所以扯远了，恐怕论坛上很难扯清楚，呵呵

(三天前写的,不能白写,先发了吧)

真的忍不住要说一说.

1,首先说说分层和架构的问题,我感觉这是两个层次的概念.架构设计我认为首先要考虑的应该是数据流,以及功能模块的划分.分层只是架构设计要考虑问题中或者说标准中的一个部分.

2,"凤舞凰扬:PO是持久化对象",这句话应该没有问题.
"它只是将物理数据实体的一种对象表示","所有的表现与数据库的存储完全挂钩，既然这样，就不要谈什么架构了，谈架构就是笑话。",这些话好像就有些问题了.我的理解应该PO是有将自身进行持久化(存入数据库)的能力的一种对象.  这应该是把持久化对象,和对象数据库,两个概念混淆了.或着还是以数据库为软件结构(架构)的核心,而没有以对象为核心.虽然在大型系统中,这很难做到,但我认为这却是hibernate的真正核心思想. 为什么不把 业务实体对象 直接持久化呢?(如果采用hibernate就要首先忘掉数据库)


3,再说说PO,VO(value object ),actionFormBean.我认为持久化的对象和MVC层次没有直接的关系.
在一般系统内,对业务层的对象可直接持久化,PO就可以作为VO,是业务对象状态的直接反映.如果由于性能,功能,第三方集成 甚至是系统结构设计等原因,在业务层下还要有存储层,那就应该是所谓专门的PO了.(凤舞凰扬做的系统).甚至也可以在view或control层对输入的数据对象持久化,actionForm可以直接作为PO使用,这时的PO不是业务对象的PO,而是输入数据对象的PO,比如用作存储转发,缓存等.
虽然直接对业务实体的状态直接进行持久化是理想的业务系统结构,但由于历史或性能等原因,你很难对业务对象进行直接的持久化,尤其是在大型的异构的多模块的系统中,不过这时候你为什么还要使用hibernate呢,那样好像就真的只有跨数据库的好处了.

4,所以我认为不是PO是否可以传到表现层,而是VO是否可以传到表现层的问题.这个我认为既然采用MVC结构,那把VO的数据copy到formBean中再用于显示我认为不失是一种降低层次间耦合度的好的优雅的方法,(虽然在我作的三个百万以上的实际的业务系统中也没有这么做,可能是因为逻辑简单),实际上如果对于单纯的在两种对象直接copy属性的化,到底对降低耦合度有哪些具体的帮助我还没有想清楚(模块间界耦合度应该是接口的简烦程度上,以对象作为接口,一个对象要变接口,两个对象也要变接口,怎么就降低耦合度了).如果是jsp+bean的结构,直接使用VO就行了.这个问题总的来说我同意 凤舞凰扬 的.

好久没看到这么精彩的帖子了啊，过瘾～

同楼上一样，我也没明白为什么加了VO就能让耦合度降低。看好多VO的实现不过就是一个PO的clone罢了。如果我的PO变化，VO不是一样要变化么？VO变化那么往上还不是要变化么？

举个最简单的例子，如果有一个字段，你取名为password，但是它在某些数据库是关键字，会冲突，要改（你不能保证你所有取的名不会出现这样的情况吧？更何况还是你主动改），你数据库做移植，没有办法，你需要改你PO的名字（当然，如果是通过映射的话这个还好解决，如果是映射解决不了其他问题呢？），如果PO一直传过去，那么岂不是需要改动所有的地方呢？
    道理就这么简单。

其实你说的恰恰相反。 道理很简单，你需要修改的不是PO而是和数据库表映射的关系。所以，可能你说的情况并不能说明问题。

大家分别给架构下一个定义吧，什么是架构，什么不是架构？

大家都经常会谈论到架构这个词，这个词给人的感觉是架构是一个非常重要的东西。我认为，架构可以说是资深的程序员对系统设计的理解。我们常常说架构是将系统在最高层面的分解，所以我们经常会将一个系统的架构描述为不同的层次并用layer来描述架构。
    一般来说，现在我们的系统都会有三个层次。就是，表现层，业务逻辑层，和数据源层。根据不同的系统类型，在这三个不同的层次中，我们会采用不同的架构模式。
   先从业务逻辑层开始讲起吧，一般来说大家在做这层的设计时为了将复杂的业务逻辑能够实现为具体的代码并且易于扩展，减少重复的代码，会花很多功夫在设计上。根据Martin Fowler的定义，他将在业务逻辑层的设计分成了三种模式：Transaction Script，Domain model,Table Module。Transaction Script 是三者当中最简单的一种。它非常适合过程化的模型，大多数人对此非常熟悉并且也感到很舒服。因为，它在一个很容易理解的过程脚本中很好的封装了系统的每一个具体的业务流程。而且也非常容易在关系数据库的基础上进行开发。但是，它的缺点也不容忽视－－在业务逻辑比较复杂的情况下，它非常容易引起重复的代码。不过，如果我们的系统只有一个购物车并且计价的逻辑也很简单的话，使用这样的模式也非常合适。其实我们经常实践这样的模式，比如在SLSB或者POJO中封装所有的业务逻辑。Domain model则是三者中最复杂的。Domain model简单来说将就是将业务逻辑和业务数据封装在一起，而不是将它们分离。它非常适用于复杂的业务逻辑。但它也有它的缺点，首先它不易于学习怎样来使用一个Domain model，如果用的不好可能会带来灾难性的结果。其次，它在连接数据库方面需要有ORM的支持或者直接使用对象数据库，后者可能不太会有人将他们实施在一个真实的项目中。Tabel Module则是上述两种的一种折中，它非常时候在有像.Net这样的开发环境中来实践。我没有这方面的经验也不敢多说，不过从中我们可以看到选择不同的架构和我们手里的工具也有一定的关系。
当我们决定了业务逻辑层的模式后，往下就是考虑使用怎样的数据层的模式来配合之。如果，我们选择了Transaction Script，最简单的就是直接在业务逻辑的脚本中加入数据库的操作。不过，即使在最简单的情况下，估计大家也不会这样做的。所以我们通常会将数据库访问的代码分离到其他地方，比如说DAO等。同样的，相对应于Domain model就会需要ORM来实现数据持久化。本贴中涉及的PO其实指得是没有domain data的domain object，他将domain的数据封装在PO中，但并没有将业务逻辑包含其中，业务逻辑还是以Transaction script的形式出现，所以还是会引起重复的代码产生。对于像Martin Fowler这样的OO狂热者，他会选择domain model。在我看来，由于有了像hibernate这样的框架，ORM已经不需要自己实现，所有选择domain model是很自然的选择。主要的问题在于一个系统除了业务逻辑外，还会有一些系统的逻辑，比如说事务，jndi lookup等等，这些不能放在domain model里面，所有可以在domain model之上再加一层service layer来解决这些问题。

如sayor所说，这个例子不能说明问题，我只需要在.hbm.xml文件中修改映射关系就可以了。

TO yangzheng：
[img]关键是楼主没有做过这方面的项目，如果在项目中采用“PO传递到表现层”就会吃到苦头。
我已经吃过这方面的苦了。
[/img]

请问：如果你在项目中 直接采用“PO传递到表现层” 就有什么苦头吃了呢？

还有，如果我的表现层是采用GUI（其实我想跟JSP都差不多啦）的，在GUI的前提下，如果我把持久层传过来的PO和jTable中的某些字段（并非所有字段都和数据库中表的字段一一对应，而只是某些要给客户看的编辑的字段）对应有何不可？

还有，TO 凤舞凰扬
如果，表现层如果不和数据库层挂上钩，那么我想问问：客户录的数据如何存放到数据库？？
无论架构如何，你是不是不论怎样 都需要直接或间接的把需要的字段都转换为和数据库表相对应的对象（转换或封装过程我个人认为在GUI客户端进行）？那么，我如果直接把PO的某些属性和GUI某个jTable（例如）相对应的话  不行吗？ 我不知道自己的理解是否对：按你的意思是否把从数据库中取出的PO取到中间层 或GUI层，然后再在GUI层或中间层构造和jTable相对应的对象来显示  对吗？？
那么这样做，不又增加了对象内存的开销了吗？还有  就是这样转换过来转换过去的，难道不闲麻烦吗？

我今年刚刚毕业，目前在公司做GUI+EJB+hibernate+DB开发，我设计到前面两层的开发工作。。。
（我只是凭我目前少的可怜的理解提出的问题的，^_^ 希望各位能耐心的讲解，呵呵）
在前面各位大哥讨论的我的确有不少疑问，我如果不问的话觉得心里总有些疙瘩，问出后又觉得自己的理解  肯定有不少问题，所以希望各位能多多给予帮助和指正！

其实，我们平时所说层次之间要分离指得是逻辑上的分离，而不是数据上的分离。在一个系统中，数据总是会扩散到各个层次，分离并无实际意义。DTO完全是为了远程的调用避免太多的参数和多个返回值而使用，在使用了domain object的情况下，数据已经被封装到对象中，所以DTO也是多余的了。所以我认为po传到jsp上并没有问题。