| 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 |
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:
public class Order implements java.io.Serializable {
public String productId;
public int quantity;
...
}
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.