将业务层返回domain model 转化为 xml 发布（比如burlap）
然后在表现层用js捕捉……

现在有个很好的国产框架bufflo可以做到~~
全新的开发体验和用户体验yeah

DTO 那个东西的核心逻辑是“粗化通信粒度”，本意是为了克服 EJB1/2 的性能问题。在 ORM/EJB3 环境下，EJB2 中 ENTITY BEAN 的性能问题已经不复存在，DTO 的广泛渗透也由此成为一个不折不扣的“反模式”。

DOMAIN MODEL 既作为 ENTITY， 又作为 BUSINESS LAYER 的操作对象，本来就是 ORM/EJB3 的设计本意。非要把 EJB2 里那些补丁“模式”搬过来，

为什么好几天的记录都没了？天灾还是人祸？呵呵

> >
> 我想这应该是框架 的 设计有关吧。在 open session in
> view的 模式下是存在 这种 危险的 。不过我一般 设计
> 都是 在 business layer里操作 domain model,然后把
> domain model作为一个 普通 vo抛给 view去 操作
> 。尽管听说 open session in view有种种好处 ，但
> 我还是觉得我的这种方法 （tmd不知道叫什么名字
> ，好像叫 open session per
> transaction吧）在设计上比较方便
> ，当然这只是适合我们这类的项目。如果 有特殊需求
> ，当别论 。

初学Hibernate的人虽然掌握了新技术的“技”，但是没有掌握新技术的“道”，这个链接中：http://www.jdon.com/jive/thread.jsp?forum=62&thread=23720

它画出数据库物理逻辑图，然后再使用Hiberante配置，也就是在O/R Mapping关系中，他不是首先定义好对象Model（也就是O），而是首先抓住数据库（是 R），就是典型的使用Hibernate本末倒置，最后导致什么结果呢？

导致我前面说，在表现层 Model组件层 数据库持久层这个多层中，因为表现层是根据需求确定不能随意更改，现在他又确定了数据库层，这类似地震原理，两个版块相挤（表现层版块和数据库版块），最后混乱地震的是表现在哪里呢？无疑是中间层，这时，只能用大量临时DTO来补救，进行前后台调和，也就是和稀泥。

这种情况下的DTO造成了系统混乱，甚至失败，但是它不是DTO模式的错误。

老板说说 DTO 在OR映射框架下有什么（可量化的）意义？

作为交流，我还是说出一些我个人看法，现在我都犹豫了（说出自己想法被人认为是较劲;不说出被人认为是无科学精神，呵呵，开玩笑），我还是说说，说不定我思维有些问题呢。

我看DTO模式历史是这样的：
最早是VO也就是ValueObject, 后来，TSS那个架构师编写的"EJB模式"（至今还在TSS右边挂着呢，在EJB方面，TSS比我还死挺），将ValueObject称为DTO模式，并且还详细说明了DTO模式的几个变种，算是专业厉害了，后来J2EE Core Patterns也使用DTO替代它以前版本的VO了，当然这两者先后不重要。

一般模式使用是没有实际作用的（只是纯设计要求，不用这个模式程序照样可以跑，没什么两样），在“EJB模式”中，认为使用DTO模式可以省却客户端和EJB之间的通讯，将所有的数据或对象打包成一个对象传到EJB层，而不是一个参数一个参数的传送，每次传送都有可能涉及远程通讯和序列化，那多耗费性能啊。

后来，Hibernate出现了，提出数据的POJO，实际是VO概念，在这种情况下，VO和Domain Model可以合二为一，按照DTO模式定义：Data Transfer Object，这时Domain Model也是DTO模式实现一种，Model直接作为数据传送啊。所以，这种情况下：VO Domain Model 或DTO都是同一个东西，我觉得讨论他们区别没有意义，当该对象作为类图分析实现时，它是Domain Model；当该对象作为数据传送，它是DTO/VO。

DTO模式什么情况下不是Domain Model呢，就是我上帖举的例子，他不是从域模型驱动分析设计开发的，而是基于传统的数据库驱动设计，首先设计出数据库，再使用OR框架导出一个附属结果，这个附属结果并不是Domain Model，而是一个DTO，单纯传送数据用，这就造成了系统混乱。

不知我有无表达明白？这是我目前的想法，可能与一些权威思想不一致，也希望交流提高。

以Busiess域为中心

基本全部同意。唯一保留的一点是这样的设计还算不算DTO。因为已经完全没有DTO的原来意思了。

其实上面关于 AJAX 的讨论和这个话题也有些关系，原因是这样的：

象DTO这样，以“粗化粒度”为精髓的模式，除了在持久层以外，也出现在表现层。表现层里出现 FORMBEAN 的原因，在本质上是试图减少 HTTP 通信的逻辑产物。正是因为HTML应用普遍的模式是整个FORM一起提交，才造成了JAVA端以 FORMBEAN 来抽象客户端输入的作法。而整个FORM整体提交，是以减少 HTTP 流量为出发点的。

试想，在 MFC 时代，那是的 DOCUMENT-VIEW架构相当于今天的MFC，但是MFC里的DOCUMENT很少有象 FORMBEAN 这样与 UI 输入元素一一对应的。甚至于，DOC-VIEW的经典范例常常是一个DOCUMENT多个VIEW。这个现象的根本原因，是在 RICH CLIENT 场景架构下网络传输速率不是重要限制因素，所以CLIENT-SERVER之间的交互没有必要以整个表单为单位，而可以做到高度的互动（比如 TAB-OUT 立即出发后台业务响应，并根据结果动态更新表单项目）。这种通信模式反应在程序里，就是DOCUMENT往往有更灵活多样的数据结构。比如，DOCUMENT可以只包含一个DCOM构件的REFERENCE，而不缓存屏幕输入。

这就引出了 AJAX 对 JAVA/DTO 在架构方面的影响。如果客户端用 AJAX 实施，那么数据通信模式就类似与C/S架构：从整个FORM的间发式提交、整个PAGE的整体重新RENDER，变成一系列连续的小请求，小响应通信。并且由于请求和响应都是程序可以控制的XML，所以没有额外的HTML开销。在这样的通信模式下，JAVA服务器端的数据模型就不必非要保持一个在本质上是“粗粒度缓存”的FORMBEAN，而可以有更多灵活性。

归根结底，“模式”的选择，应该根据底层技术和应用场景的特性。

> 你太客气了，叫我“老版”就可以，实际是个老版主。
> 你的观点我是同意的：当将实体Bean
> 变成一个POJO，并且实体Bean必须由本地Session调用之后，D
> O在性能使用上没有意义了。
>
> 作为交流，我还是说出一些我个人看法，现在我都犹豫了（说
> 鲎约合敕ū蝗巳衔墙暇?;不说出被人认为是无科学精神，呵
> 牵嫘Γ一故撬邓担挡欢ㄎ宜嘉行┪侍饽亍?
>
> 我看DTO模式历史是这样的：
> 最早是VO也就是ValueObject,
> 后来，TSS那个架构师编写的"EJB模式"（至今还在TSS右边挂?
> 呢，在EJB方面，TSS比我还死挺），将ValueObject称为DTO模
> 剑⑶一瓜晗杆得髁DTO模式的几个变种，算是专业厉害了，
> 罄J2EE Core
> Patterns也使用DTO替代它以前版本的VO了，当然这两者先后?
> 重要。
>
> 一般模式使用是没有实际作用的（只是纯设计要求，不用这个
> Ｊ匠绦蛘昭梢耘埽皇裁戳窖凇EJB模式”中，认为
> 褂DTO模式可以省却客户端和EJB之间的通讯，将所有的数据?
> 对象打包成一个对象传到EJB层，而不是一个参数一个参数的?
> 送，每次传送都有可能涉及远程通讯和序列化，那多耗费性能
> 　?
>
> 后来，Hibernate出现了，提出数据的POJO，实际是VO概念，?
> 这种情况下，VO和Domain
> Model可以合二为一，按照DTO模式定义：Data Transfer
> Object，这时Domain
> Model也是DTO模式实现一种，Model直接作为数据传送啊。所?
> ，这种情况下：VO Domain Model
> 或DTO都是同一个东西，我觉得讨论他们区别没有意义，当该?
> 象作为类图分析实现时，它是Domain
> Model；当该对象作为数据传送，它是DTO/VO。
>
> DTO模式什么情况下不是Domain
> Model呢，就是我上帖举的例子，他不是从域模型驱动分析设?
> 开发的，而是基于传统的数据库驱动设计，首先设计出数据库
> 偈褂OR框架导出一个附属结果，这个附属结果并不是Domai
> Model，而是一个DTO，单纯传送数据用，这就造成了系统混?
> 。
>
> 不知我有无表达明白？这是我目前的想法，可能与一些权威思
> 氩灰恢拢蚕Ｍ涣魈岣摺?
>

废话就不说了，进入正题，当然我是基于JSF来表述自己的观点的。先大概描述一下我开发时用到的各个层？然后再逐个回答一下楼主的问题：
看下图

在这个图中，DTO的属性从 FORM 提交上来之后，就已经附合DAO层的需求了（大部分情况下），不需要再进行处理了。

下面回答楼主的问题：
1、上图中的DTO都是通过 method(DTO) 进行传递的，不需要 renew。
2、在读取操作这个过程中，DAO的DTO最终要传递给Handler，所以并没有直接使用model中的对象。
3、JSF自带的功能就可以处理String->Date的转换；confirmedPassword则可以利用JSF的自定义组件或自定义Validator实现。
4、其实由上图可见，就是同一个DTO通过传递应用到了不同的层中，如果有特殊要求可以直接在DTO中加入新属性来实现，没有新建DTO的必要。

说了这么多，又做了个图累死我了，还望大虾们刺我啊！！！

所以，DTO能否“透传”取决于你对系统本质认识和设计，这是我的主要意思。

DTO在各层"透传"，说白了，DTO是各层的全局变量，这只是设计上的全局变量，也就是说DTO体现了各层所要对象的共同特性，各层的设计都要围绕共同特性进行布局。