Value Object Layer - How to be a Successful Technical Architect for J2EE Applications
 |
|
Value Object Layer
Every application has data items that logically belong and typically are used together. It's programmatically convenient and, with enterprise beans, performance enhancing to treat this logical group of data items as a separate object. This type of object is commonly known as a value object (VO), although some texts refer to it as a data transfer object. If Java had a "structure" construct, as C/C++ and many other languages do, a VO would be a structure.
For example, you could combine various pieces of information for a report template into a VO. Methods needing a report template argument could then accept the ReportTemplateVO instead of individual arguments for all components of the structure.
Typically, a VO has accessors and mutators but little else. And usually a VO implements java.io.Serializable so it can be transmitted to remote application clients. J2EE containers and RMI services serialize the content of Java classes before transmitting them to a remote machine. A common convention is to give value object names a VO suffix, as in CustomerVO.
Common Patterns
The value object originates from a formally defined pattern. In some texts, this pattern is called the value object pattern (Alur, Crupi, and Malks, 2001). The VO pattern enhances EJB performance but is useful in communication among all layers of the application.
You can combine the VO pattern with the composite pattern, which is used when something contains other things. For instance, a report template often contains multiple parameters. Using the composite pattern, the ReportTemplateVO contains an array of ReportTemplateParameterVO objects, as illustrated in figure 5.4.
|
|