Preparing to Implement the Partial Population Pattern

The Partial Population pattern has similar implementation notes as the Data Transfer patterns, with a few extensions:

The effect the Partial Population pattern has on performance is entirely coupled to your particular environment: Using a pure object-oriented environment with no additional technologies, the pattern implementation will likely slow performance. This slowdown will be related to additional branch cases required by your code to check for null data and take action on non-null data. If you use a persistence environment and are experienced with it, you may be able to get better performance by tuning your data retrievals to only the data necessary. The complexity of your objects and the level of nesting of complex object types will also change the performance characteristics. Consider a case where a consumer requests attributes from only the top-level object. This will perform much better than a query for deeply nested objects.

The deeper the nesting of your Business Object pattern implementation with complex object types, the more complex your key mechanism needs to be: To get the most out of a Partial Population pattern, you want to allow clients to specify data at an arbitrary level of nesting. Unfortunately, the mechanisms to support an arbitrary level of nesting will themselves become complex to your service implementation. The flatter Business Object pattern implementation promoted throughout the book makes key implementation easier; however, again, you lose your object orientation by pursuing simplification.

The extreme implementation of this pattern is the inclusion of a query language as a first-class component of your service environment: Although I do not recommend including a query mechanism on a Web Service model, implementing a generic query mechanism within a single architecture is an interesting proposal. The multiple architectures of aWeb Service model make a query mechanism difficult to consider. If the query mechanism has object semantics, you would lose the understanding of Web Service consumers who use non-object-based Web Service clients. The only generic query mechanism worth considering for a Web Service would probably be SQL, but translating it into more robust object-oriented architectures becomes difficult.