开发者的接口。在一个项目的开始阶段,客户端和服务器
开发者需要在决定使用什么ejb interface的同时决定
data transfer object的
设计。不管这个需要,因为
开发者通常不完全懂得什么数据单元应该在客户端和服务器
之间传输,所以在项目开始阶段设计data transfer object
是很困难的。
开始设计data transfer object的简单方法是作为服务器端
entity bean的拷贝(或领域对象),如Domain Data Transfer
Object模式所述。设计Domain Data Transfer Object很简单,
因为项目小组通常有项目可以初期使用的好的领域模型。因此,
把Domain DTO作为客户端和服务器之间的交换能让小组启动和
运行得更快。
终极的,客户端和服务器之间交换的数据应该设计得去满足
客户端的需要。因此,当项目进行并且客户端的需要满足了,
Domain Data Transfer Object作为交换单元经常变得难用,
太过于粗粒度以至于无法满足客户端的细粒度需要。一个客户
端可能需要存取没有被封装在任何Domain Data Transfer
Object中的数据。在这一点上,开发者可以设计custome Data
Transfer Object,就是说,封装任意数据集的Data Transfer
Object,完全被客户端的特定需求所驱动。
这两种设计paradigm的区别会对整个应用的设计产生显着
影响。虽然它们代表自相矛盾的方法,他们可以通常在
任何
J2EE应用中共生。
当决定何处放置创建和消耗Data Transfer Object的逻辑
时,Data Transfer Object Factory模式描绘了一个可行的
并且可维护的解决方案。一个和跨层(DTO,HashMap,RowSet)
的任何种类的数据传输一起发生的事件是:当数据到达客户端
时,它有潜在的不是最新的可能性。Version Number模式
能解决这个问题。
相关模式
State Holder
value Object
Details Object