Home

This Chapter
-Chapter 1: Model 2 and Struts
-Transfer Objects
-A Primitive Model 2 Application
-Employing View Manager and Action Manager
-Enter Struts
-A Struts Example
-The MVC-ness of Struts
-Summary

Table of Contents
-Introduction
-Chapter 1: Model 2 and Struts
-Chapter 2: Input Validation with Action Forms
-Chapter 3: The HTML Tag Library
-Chapter 4: Input Validation and Data Conversion
-Chapter 5: The Validator Plugin
-Chapter 6: The Expression Language
-Chapter 7: JSTL
-Chapter 8: The Bean Tag Library
-Chapter 9: The Logic Tag Library
-Chapter 10: Struts-EL, Nested, selectLabel
-Chapter 11: Message Handling and Internationalization
-Chapter 12: The Tiles Framework
-Chapter 13: Securing Struts Applications
-Chapter 14: The Config Object
-Chapter 15: The Persistence Layer
-Chapter 16: Object Caching
-Chapter 17: File Upload and File Download
-Chapter 18: Paging and Sorting
-Chapter 19: Preventing Double Submits
-Chapter 20: Early HttpSession Invalidation
-Chapter 21: Decorating Request Objects
-Chapter 22: How Struts Works

Previous
Next

 

Transfer Objects

The concept of transfer objects in J2EE is simple and easy. A transfer object contains only data elements and no business logic. By contrast, a business object has both business methods and data elements.

The main purpose of using transfer objects is for efficient data transfer across tiers, e.g. from the presentation tier to the business tier and vice versa. Suppose you have a business method called insertOrder(Order) in an Enterprise JavaBean (EJB) that you call remotely from a servlet. The Order object argument must travel from the presentation tier to the business tier (probably running in a different Java Virtual Machine). Having the Order object as a transfer object will result in a more efficient remote method call. The insertOrder method is only interested in the values of the order (such as product id, quantity, consumer id, etc) in the Order object anyway, and will never need to call a business method on it. Therefore, the Order class does not need business methods.

A transfer object must be serializable, i.e. its class must implement the java.io.Serializable interface. There are two reasons for this. First, objects that need to be transferred in a remote method invocation (RMI) call must be serializable and the EJB technology uses RMI as the communication protocol between an EJB and its client. Consequently, transfer objects that will be passed to an EJB method will have to be serializable. The second reason has to do with the fact that servlet containers may serialize their HttpSession objects to secondary storage when the memory is getting full. Since transfer objects are often stored in HttpSession objects, transfer objects must be serializable for the object serialization process to be successful.

A transfer object can expose its data values in one of two ways:

  1. By exposing the data elements as public fields:
         public class Order implements java.io.Serializable {
           public String productId;
           public int quantity;
           ...
         }
    
  2. By using properties, i.e. a data element is represented by a private field which is accessed by a public get method and a public set method:
         public class Order implements java.io.Serializable {
           private String productId;
           private int quantity;
           ...
    
           public String getProductId() {
             return productId
           }
           public void setProductId(String productId) {
             this.productId = productId;
           }
           public int getQuantity() {
             return quantity;
           }
           public void setQuantity(int quantity) {
             this.quantity = quantity;
           }
           ...
         }
    

Both work well, but the second approach is the only option if you want to use JSP Standard Tag Library (JSTL) or Struts custom tags to access transfer objects referenced by scoped variables. This is because JSTL and many other custom tags are designed to work with JavaBeans. The Order class in the second approach is in fact a JavaBean that implements java.io.Serializable.

To make transfer objects more recognizable, it is good practice to add the suffix TO to their class names, e.g. OrderTO, ConsumerTO, etc.

Another related term is “value object”, which by definition is an object that only contains value or data elements. A transfer object is therefore also a value object. Both value objects and transfer objects are often used interchangeably even though the purposes of having them can be different.

Previous
Next