Preparing to Implement the Data Transfer Patterns

Using the Data Transfer patterns is not a question of whether you will or you will not, it is a question of how often and where to use the patterns. In general, clients want simplicity and flexibility in the Application Programming Interface (API), and a proliferation of the Data Transfer patterns can create ambiguity as to which API the client should use. Practicing using the Data Transfer patterns is an exercise in striking a balance between providing the client the data they want in a useful bundle and creating a cluttered interface to the Web Service. The following guidelines are useful for the Data Transfer patterns:

Use the Data Transfer patterns when you expect the client to retrieve more than one data item from a server-side object: The purpose of the Data Transfer patterns is to improve performance but also to give a natural API to the client. Combining data that is not typically in a single retrieval group would be unnatural for a client and therefore is not encouraged. For example, if you are tracking personal preferences for a customer, retrieving their credit card number and the type of coffee they enjoy drinking would not be a natural pairing of data. On the other hand, bundling all of the order information, such as the ordering address and credit card information, may be appropriate. In either case, bundling five properties into a single operation reduces the number of traversals across the Web Service environment by eight, assuming a client wants all five properties. This is a substantial performance gain for the client.

The Data Transfer patterns can apply to the entire property set in a single object: This implementation of an object is typical when you think customers will frequently want a large set of data from the object. This implementation creates a mirror of an object implementation but without the behaviors of the object and with a simpler mechanism for accessing the data. A common example of this usage is in management applications. Often, clients will present all of the properties of a managed element in a user interface to monitor the status of the element. Rather than traversing the physical tier boundary between the presentation tier and the logic tier for each property, it is easier to traverse the tier boundary a single time for all of the property data. The performance gain is also substantial, often from 25 calls to a single call. If a call is 100 milliseconds each, you are moving from 100 milliseconds to 2 1/2 seconds. Even considering that you may increase the response time, because of additional data, to 1 second (a very conservative guess), you are saving a lot of time for clients.

There can be more than one Data Transfer pattern implemented for a single server-side object: The balance you want to strike for the pattern is to avoid pollution and confusion in the programming interface while allowing clients to access and change data in the most efficient way. For example, a customer business object contains a wide variety of data that could make up several data transfer objects. The pattern implementations on the customer business object could include one for shipping information, one for ordering information, and one for the customer profile presented in the browser to the customer. For example, shipping information may contain a shipping address, the customer's choice of shippers, and related information. Ordering information may contain credit card numbers , billing addresses, and related information.

Do not add behavior to the Data Transfer patterns: Once you add behavior and calculations to the Data Transfer pattern, you cross a line into creating a more complex object type. For example, moving information around a network relating to an order adheres to the Data Transfer Object pattern. On the other hand, adding behavior to calculate sale discounts to the Data Transfer Object pattern itself would break the pattern implementation. The data transfer object is just for passing data between a client and a server-side object, nothing else. A simple guideline is Java's public instance variables . If you cannot access the data in the object directly from the public instance variable, you have crossed the line out of the Data Transfer Object pattern. For example, adding a getTotalCost() operation to the Data Transfer Collection pattern that calculates the price of all the contained data transfer objects crosses the line from flat data to derived data.

The set operation on a data transfer object instance or a data transfer collection instance should be a single transaction: Often, on server-side components , each set method will begin and commit a transaction. The DataTransferObject instance gives a natural boundary to the scope of a transaction by grouping common properties together in a Data Transfer pattern. You can create your attribute groups on your Data Transfer Object pattern to ensure that clients cannot put data in a partially updated state.