是的,在一些框架里面,你不得不不用其他的对象,例如strcut,你也许需要转换成formbean来使用.但是你如果使用webwork,那么很庆幸,你可以轻松解决这个问题,实现ModelDriven就可以让你的表现层轻松访问你的domain object.用dto来作为service的参数,将使你的domain object的威力有所减弱,service的接口膨胀,让client再次感觉到结构化编程的痛苦.嗯?我需要调用service,传入一个部门的dto或者Id来得到部门里面的人员码?不,部门(domain object)本来就应该知道它有哪些人.
域模型不是我想出来的,是别人提出来的,这个你算是说对了 ,估计提出这个的人也中了OO病毒,也许比我严重的多 :).
我提出这些,只是觉得这中方式可以更好的进行OOD,这个不是概念,是开发中很实用的设计方式.
知道域模型不能怎么样,至少不能成为比尔,哈..其实不用它也可以解决问题,有朋友和我说,我在jsp中写全部的代码,比你的方式快,而且方便.呵呵..我对他说,你算是说对了,不过你要加上一个环境描述,那就是你做的是一个hello world...任何设计和实现方式都有它的理由和使用环境(Context),我一再强调这个.
使用那种方式多没有对不对的问题，只有好不好和合不合适的问题。
大家在这里探讨问题目的是为了相互借鉴相互提要，找到更合适的方式。
DAO+VO方式也许是可行的一种方式，但不一定是一种好的方式。如果认为这种方式好的，可以说说它好在哪里，
能增强系统的灵活性和扩展度吗？
能提高开发的效率吗？
有更好的可重用性吗？
能有效的提高系统的性能吗？
等等，
如果能也请说说问什么。
还有如果是把要数据和操作完全分开，那是不是等于说ADT(抽象数据类型)毫无价值了呢？由此推论是不是可以说明基于ADT的面向对象理论是没有任何价值的呢？
TO 浆糊，表现层直接访Domain object，会不会造成domain object和表现层紧耦合呢？例如为在表现层显示所有部门的所有用户，在完全不要服务层的情况下得到所有部门的所有用户这个方法是放到部门类里还是用户类里呢？
但我不是说域模型不好！！
我觉得显示层使用doamin 对象可以更方便的达到需求,不需要做domain->dto的转换,其实说到耦合,我认为dto不能和好的解决显示层的耦合,如果domain变化了,dto大多数情况下还是需要变化.
服务层是需要的,但是它的职责只是facade,不是business logic.所有部门的下的用户,我一般的处理方式是使用repository模式来解决,因为它是对entity的一个查询,可以不纳入domain object的方法中.
TO:zhuam
domain object是业务概念的一种表现,只会关注属于它自己的属性和方法,所以说只有符合或者不符合业务模型的domain object,不会说是过渡肥大或者瘦小.让doamin object尽量真实的反映实际的业务对象是关键.
还有道兄说的changePwd方法的位置.我认为这是一种分配职责的过程.根据Larman的研究，这种分配职责应该是按照“信息专家”的模式来分配的。即谁拥有完成该职责的信息，就将该职责分配给他。那么user中拥有这个方法是非常对的，而你所说的UserManger更应该是委派的角色。
这种说法我亦不敢苟同。什么是域模型？难道你的领域模型只有表示状态的属性，而没有动态的行为？这叫什么领域模型呢,详细客户都不能答应你。当然，有时候从设计或者开发角度考虑，将领域模型简化成你所说的数据模型，这种情况是存在的。但是这种情况下，这个模型已经不是领域模型了，已经编程了一个为了持久使用的领域实体模型（PO），他不再是POJO。
^_^，不好，有看到了一个我不能接受的说法。域模型是用户业务领域的反映，在考虑域模型的时候，我想大家并没有考虑如何进行持久。而当我们进行设计的时候考虑的是持久层的解决方案，才引出了o/r mapping。你所理解的域模型就如同我理解的PO，如果你硬是要把PO说成是域模型，那么^_^后果就不要我说啦。
所以感觉你的理解是有问题的。
和
感激不尽!
jehad_shi@163.com