> 不是没有可能，即便如此，虽然view层的无法获得session,但
> 撬梢匀我庑薷persistence层的对象也是很危险的，persis
> ence层是不会对数据进行验证的，它只会不管3721的保存数据
> ?>
> 我们应该确保各层之间认知程度最低。
>
我想这应该是框架 的 设计有关吧。在 open session in view的 模式下是存在 这种 危险的 。不过我一般 设计 都是 在 business layer里操作 domain model,然后把 domain model作为一个 普通 vo抛给 view去 操作 。尽管听说 open session in view有种种好处 ，但 我还是觉得我的这种方法 （tmd不知道叫什么名字 ，好像叫 open session per transaction吧）在设计上比较方便 ，当然这只是适合我们这类的项目。如果 有特殊需求 ，当别论 。

可能会流行的一种方法

将业务层返回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吧）在设计上比较方便
> ，当然这只是适合我们这类的项目。如果 有特殊需求
> ，当别论 。

我觉得DTO模式是一种实践中的模式，它出现有很多因素，Yin认为和EJB有关，我认为更多和人们非对象化思考有关，但是DTO模式本身是中性的，用得不好成反模式，例如这个案例，

初学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作为模式最早出现在J2EE CORE PATTERNS, 原因就是为了克服 EJB1/2 的性能问题。在 EJB3 框架下，主要指在LOCAL ENTITY + OR MAPPING的框架下，DTO模式至少没有任何性能上的实际意义。在EJB3里用DTO，有点在C++里用 void * 的感觉。当然当年很多人就是喜欢写这个 void *“模式”的代码。

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

你太客气了，叫我“老版”就可以，实际是个老版主。
你的观点我是同意的：当将实体Bean 变成一个POJO，并且实体Bean必须由本地Session调用之后，DTO在性能使用上没有意义了。

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

我看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域为中心

I C.

基本全部同意。唯一保留的一点是这样的设计还算不算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，单纯传送数据用，这就造成了系统混?
> 。
>
> 不知我有无表达明白？这是我目前的想法，可能与一些权威思
> 氩灰恢拢蚕Ｍ涣魈岣摺?
>

严重同意Kyle_Yin关于"应该根据底层技术和应用场景的特性"选择模式的说法。
但是模式的名字让大家跑题了，我并非仅针对DTO和ValueObject提问，也不是想探讨“粗粒度XXX”。我是想知道持久层对象和业务层对象以及表现层对象是否可以“透传”？到现在还没有人告诉俺呢。至于AJAX的使用，本人认为应该控制在表现层范围内，不要让他影响整个架构。也就是说那些“小请求，小响应”应该仅针对页面，而业务逻辑仍然需要靠“大请求，大响应”激活。

我认为，可以透传，但透传的这个“东西”应该既不具有持久层属性，也不具有业务层特点，更不可有表现层的特证。也可以说三者的特性都有，这样就可以透传了。按照BANQ的叫法可以透传“域模型”吧。

唉，我还是没有表达清楚。域模型是要的，而且一个系统就一套，当然不需要每个逻辑层一个。域模型是架构方面的问题，而我说的是“对象”（有时候就是域模型的实例）的传递，这个对象在各个层之间的表现是不同的，尤其是在持久层，所以我想知道别人是如何解决的。

透传一个就行，我有时用数组，有时用弹性Bean，有时用Property.有时干脆用一个bean.关键是不要被概念给缠住。

本人开发项目已有三年了，在此发表一下自己的观点，还望大虾们不吝赐教啊。
目前本人主要用JSF开发软件，对EJB还只是了解，并没有应用到项目中的机会。
曾有一段时间用STRUTS做了一个样例的程序后，开始接触JSF，然后就爱上了这个东东（个人感觉自己有些崇拜标准的倾向）。不过不管怎么说，工具就是工具，用什么怎么用全看公司，项目，个人。。。。总之很多因素的需要了。总之用好就行，行行出状元嘛，也祝各种技术越来越好，功能越来越强，好像有点语无伦次了。。。。。。

废话就不说了，进入正题，当然我是基于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的必要。

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

lijinlinlin 辛苦了，DTO在一般情况下可以在各个层次之间“透传”，我们知道，“透传”有很多好处，方便简单，但是在复杂系统中，要实现一个DTO能够“透传”，这个DTO的对象一定得设计好，体现系统的本质，而域模型分析方法一般可以达到这个目的。

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

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