关于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是什么类型呢？为了某一个业务，构造一个单独的javabean？那么actionForm、hibernate Po 、DTO ，是不是在一定程度上有一个很大的重复呢？
2 如果我把DTO构造成我自己的一种类型，里面的属性方法怎么设计呢？粗略以为：用两个String属性标示要处理的Po和要进行的操作，用容器来装数据 。 那么这样，我又对这个值对象是否能完成我的所有的业务功能表示了怀疑 ， 或者我理解的这种DTO的说法根本就不合理呢 ？

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

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

DTO基本上是值对象，只要表明实现序列化接口。
用javabean即可。
比如：

KillManDTO

public String getManId(){
  ...
}

public void setManId(String id){
...
}

重复肯定是有的。但DTO和PO还是有差别的。PO有着内在的实体关系，而DTO的目的还是面向传输的。

矛盾在于很多DTO的存在是PO的一个可怕的重复。
但是因为显示与业务的差异，如果没有DTO会
使PO过度的暴露在显示层，维护工作很大。
还有一个疑问是DTO是否需要维护和PO一样的对象
间的关系。

有一个想法就是在一些情况下，把po（或者bo）传到显示层，但是在显示之前
用一些代码把它格式化一下，这样不需要大量复制po的逻辑到dto，又可以使
显示和真正的数据分开。用类似velocity的模板或随便什么管用的都可以。不知道各位怎么想？

其实把PO作为DTO用就可以了，尤其是不涉及到EJB的WEB应用，再增加一层DTO更加没必要。

同意，PO有状态，但是DTO也不会像VO。
VO和BO本身是为了维护业务状态和持续做
准备，和显示用的DTO完全谈不上像不像。

实际上PO也可以是业务无关的，PO也不是一定要有状态啊，你把他当一个DTO对象来用不就行了。

平时多了解良好的设计是非常必要和有益的，但用之前一定要问一问自己，我解决这个问题真的有必要这么做吗？keep it simple是首要原则。对于你现在的问题，你的解决办法并不会给你带来什么负面影响啊。


在mvc中，controler的职责是完成构造DTO, 发送DTO , 接受返回值 , 决定下一个视图，而struts中的action，实际上是属于model。在其中包含业务逻辑也未尝不可。如果你想减少对struts的依赖，可以创建一个抽象类，抽象类中excute方法调用一个抽象方法，然后你的action继承这个类，实现这个抽象方法。ActionForm实际上也是DTO，就是mvc中用来存储数据给view显示的对象。

DTO一般都没有什么逻辑，所以按照without EJB的说法根本不需要。于是bo就直接传到了界面上来了吗？疑惑疑惑。