这恐怕就是分层结构的硬伤了,分层结构在解耦的同时也把一些有用的耦合分解开了,因此就需要各种各样的胶合剂来弥补层与层之间的缝隙.DTO就是其中的一种.

可使用代码工具来减少一些工作量.

系统分层次是为了减小减小各层次之间的耦合，但我认为想要达到0耦合是不可能的。正如Business Delegate减小了web层于ejb层之间的紧密耦合，但付出的代价是Business Delegate于ejb层之间的紧密耦合。正如楼上所说，这就像是两个层次之间的粘合剂。

DTO的目的不是为了减小耦合，而是为了减小远程调用的次数，因此DTO一定要紧密耦合于远程调用的双方，但换来了远程调用双方的松散耦合。

这个问题非常有意思，其实DTO是随着实体Bean变化的，现在jbuilderX已经提供从实体Bean直接生成的DTO的工具，说明DTO确实是依据实体Bean变化的。

所以，现在有些MDA工具，可以迅速根据Model变化，自动生成新的实体Bean和DTO等。

DTO变化肯定会影响Web层和EJB层的，所要做的只是缩小这种影响，一般我是将DTO影响限定在这个Model的增删改查框架内，因为我使用JdonSD的增删改查框架，因此，根据实体bean变化，可以迅速修改DTO变化，直至相应的客户端界面，这种修改不用担心会带来新的不稳定性和隐患。

而且，这种修改不会因为实体Bean的数据增加而显得麻烦，因为增删改查框架已经限定，每个实体Bean修改部位都是相同的，比如总是A B C三个地方。

不知道我说清楚没有？我的意思是，实体Bean变化是肯定的，现有的J2EE结构只是解耦了各层关系，但是没有提供一个沿着某个实体Bean这样纵向的联系，这样使得复杂实体Bean系统中，某个实体Bean变化导致修改环节太多，太琐碎，而我在实践早发现这个问题，使用自己的框架来建立这种纵向联系。

谢谢各位前辈给我的指点,明白一些了.

我参考了banq的“数据操作通用框架的使用”的示范代码，还有一点不太明白，想请教banq:

请问productForm是如何实现的？它和com.jdon.estore.model.Product之间的关系是什么,是否由JdonSD框架来处理二者的联系?