Seeing Partial Population in Practice

The DataTransferObject instance serves as the basis for the Partial Population pattern. For the Partial Population pattern to be useful, the DataTransferObject instance contains more than a single value. A Partial Population pattern with a single value on the DataTransferObject instance does not make much sense; however, it is possible. In a DataTransferObject instance with two values, value1 and value2 , only one of these values must be populated in a Partial Population scenario.

When looking at Figure 17-1, it is important to remember what you learned in the "An Observation on Web Services and the Data Transfer Object" sidebar from Chapter 16, "Implementing the Data Transfer Object Pattern." Specifically, the DataTransferObject instance could be the equivalent of a complete BusinessObject instance because of the way you implemented the Business Object pattern earlier in the book. You reduced the behavior on your core patterns and increased the representation of data. You moved behavior to the Business Process and Asynchronous Business Process patterns. Therefore, the information in the remainder of this chapter could also apply to the primary interfaces on the base patterns.

Understanding the Components of the Partial Population Pattern

Rather than seeing each component of the pattern in full, you will focus on the pieces of the structure that distinguish the Partial Population pattern from the Data Transfer patterns:

DataTransferObject: The DataTransferObject component is a partially populated instance of the class designed by the service's developers. An alternative implementation of the pattern could add a set of keys to the DataTransferObject component to indicate what fields are populated. For example, the key " value1 " tells the consumer that the property value1 contains altered data. On the other hand, the property value2 contains stale or irrelevant data. Without this key field, you should expect that null fields are not populated and that non-null fields are populated. In fact, enforcing the usage of nulls to identify irrelevant data helps improve performance in distributed processes because the irrelevant data does not have to be marshaled across process boundaries.

DataTransferCollection: Like the DataTransferObject component, you do not modify the DataTransferCollection component for the Partial Population pattern implementation. Further, there is not a variation for this top-level object; it remains as described in the previous chapter ” a collection of data transfer objects.

BusinessObject/BusinessObjectCollection: These classes carry the burden of the Partial Population pattern implementation. In addition to simple get / set operations for the Data Transfer patterns, these objects typically surface additional methods that allow keys to be specified. The keys identify specific data that the client wants returned; this data is a subset of the data in the DataTransferObject itself.

Client: The client interacts with the BusinessObject and BusinessObjectCollection objects to retrieve or push instances of transfer objects and collections. When the client creates the transfer objects and collections, it populates only the fields that the target service should use. When the client consumes transfer objects and collections, it consumes only fields that are populated. If the client wants to customize the contents of the transfer objects requested from a BusinessObject or BusinessObjectCollection object, they should call appropriate methods on these instances that allow keys to be specified for the appropriate data.

As in the previous chapter, you could easily replace the BusinessObject and the BusinessObjectCollection components with the BusinessProcess and BusinessProcessManager components. The important structuring to remember for the Partial Population pattern is simply that you have target Web Services with collections of interesting data and you want to retrieve that data from a client or change custom groups of that data.