关于ValueObject和DTO模式的思考

ValueObject和DTO模式是常用的J2EE设计模式，模式所体现的不仅仅是一个设计技巧，更主要的是数据封装的思想。最近我在做设计的时候却对这个模式产生了一些疑问。

1．  对于位于持久层中的ValueObject，我是否应该限制他们的使用范围？以Hiberante为例，由于ValueObject的生命周期的特性，我们不能把他们当作DTO在层间传递。但是，如果使用BeanUtils等工具复制一个的话，却总是感觉有些浪费内存。如果是EntityBean则没有这些疑问——很显然我不能把EJB Bean实例当作DTO在层间传递——浪费就浪费吧L。

2．  表现层的表单也需要对象封装，在Struts中就是FormBean，但是在JSF中却没有这样的概念，这样一不小心我们就容易在表现层直接使用model中的对象，这也是不合理的。

3．  Business层需要处理从表现层传入的数据对象，这个数据对象也不能是FormBean或其他表现层VO，因为往往这些表现层VO直接反映的是表单数据，例如一个String格式的日期或者confirmedPassword，前者需要转化为Date类型而后者则在Business层用不到，这些处理也应该在表现层处理（？）。

4．  DAO层接收Business层的数据，这个数据应是Business层对表现层数据的处理结果。

这样一来，我们在处理一个case的时候就出现了3个ValueObject：

l         一个是表现层的用于反映页面数据。

l         一个是Business层的，用于作为表现层和Business之间的DTO。

l         另一个是Domain&DAO层的，用于持久化的ValueObject。

这真是浪费呀！

结论

在Business层和Persistence层之间介入一个Domain层，其中包含Model对象这些对象既可以在Persistence层作为PO（如果使用Hibernate），也可以担当Business和Persistence层的DTO，但是，由于对象持久化的生命周期特性，我们不能把PO(持久对象)直接作为DTO使用，而是采用传统J2EE设计模式的DTO Assembler模式从PO构建新的DTO作为数据传递的介质。

至于表现层，根据不同情况，即可以使用有Persistence层直接传出的DTO也可以设计一些FormBean，所谓FormBean就是可以直接反映View数据的类，例如：
String birthday;//一般birthday都是Date类型的，String类型是为了页面使用方便