Overview

A value object (VO) is a lightweight, serializable (i.e., implements java.io.Serializable) object that structures groups of data items into a single logical construct. For example, EmployeeVO is a class in a human resources application that is a value object containing the data last name, first name, employee ID, job position, and start date. EmployeeVO is used in all layers of the application, from presentation to data access. The term value object comes directly from the value object design pattern. Some texts use data transfer object instead.

The value object design pattern, as written, is intended to minimize network traffic between enterprise beans and their callers (because each argument passed initiates a network transmission). In addition, it is designed to improve the performance of enterprise beans by minimizing the number of method arguments, and thus network transmissions, needed to call them. For example, it's more efficient to call the addEmployee() method of an enterprise bean passing an EmployeeVO than it is to require individual arguments for last name, first name, and so on. I think of the value object design pattern in much broader terms and use VOs to communicate information between all layers of the application, as illustrated in figure 10.1.

Figure 10.1: Using Value Objects Within a Layered Architecture

At first glance, my broader definition of a value object appears to contradict the principles of object-oriented design that tell us to combine data with the business logic. Those principles would have us think of "employee" as an object that contains its data (e.g., last name, first name) and methods such as add(), terminate(), and oppress() that represent business logic. For many practical considerations, such as increasing the performance of enterprise beans, we need to have the option for referencing data outside the business logic context.

Chapter 13 will show you ways of constructing objects in the business logic layer that adhere to object-oriented design principles and also allow you to reference the data portion of these objects as a value object. For example, the Employee class could easily provide a getEmployeeVO() accessor that provides the data for an employee without its business logic.