关于Struts中间如何设计DTO的困惑...

用Struts+Hibernate做了一个小的项目,一切都是新东西,我也还依然是个新手。^_^
自学了一些下载的资料,把Struts和Hibernate匆匆学了一遍后,项目除了界面外我一个人凑或着完成了,居然客户也就用起来了 。呵呵,毕业后的第一个项目!(废话好多^_^)...

看了一些资料,发现良好的设计原来是要在 action 中间构造一个 DTO,往下传给业务层,action中间只是完成转发,并不包含业务 !

看我原来的设计:
在action中间,接受传入的actionForm , 然后get actionForm中间的信息,进行业务的处理 。比如c或者u操作,把actionForm中间的属性拿出来构造一个或几个po(暂时这样叫吧),调用底层封装了事务和Hibernate持久化操作的类方法, 完成整个操作 . 这样做,缺点自然多多 .

仔细想了一下,把在action中间的业务独立出来,那么这些业务类接受DTO作为参数,进行业务的处理.这个类的好处是:
1 业务类可以同时被很多的action复用 ;
2 业务类并不接受ActionForm类型做参数,那么当技术发生变化,系统维护升级更改,就算不再使用struts,这些业务类还可以被复用 ;
3 让架构更清晰 . 确实不想看在action中看到长长的业务 。 action完成构造DTO, 发送DTO , 接受返回值 , 决定下一个视图 .

再仔细想一下:这个DTO应该如何设计呢?
在一个简单的DTO介绍上说:DTO通常用于提供细颗度数据视图,它根本就不包含任何业务逻辑.
问题:在action中间构造这个DTO
1 这个DTO是什么类型呢?为了某一个业务,构造一个单独的含有geter/seter的新对象?那么actionForm、hibernate Po 、DTO ,是不是在一定程度上有一个很大的重复呢?
2 如果我把DTO构造成我自己的一种类型,里面的属性方法怎么设计呢?粗略以为:用两个String属性标示要处理的Po和要进行的操作,用容器来装数据 。 那么这样,我又对这个值对象是否能完成我的所有的业务功能表示了怀疑 , 或者我理解的这种DTO的说法根本就不合理呢 ?

或者,我根本就没有理解DTO ?

希望大家能给我帮助! 回复我的问题,给我技术性文章、例子、帖子的url 或者msn email ... 感谢你对新人的支持!

PS:模式还没有来得及系统学习,苦恼ing ...

flashkai AT msn dot com

呵呵,能问出这样的问题已经水平不低了,我也有这样的困惑,在《EJB设计模式》这本书里有好几个模式专门讲这个问题的,但是看了感觉不太实用。

啊?
是不是帖子发错区了?
是不是要发到
设计模式、框架和架构 ?

DTO是EJB设计模式中定义的,你用的纯WEB结构,无集群分布式可能环境,所以不存在DTO概念,只有POJO或VO。