Martin Hunter

THE EXPOSABLE DATA TRANSFER OBJECT PATTERN

Background

I've been using the Data Transfer Object (DTO) pattern in the design of enterprise systems in .NET and Java for a number of years. A DTO is a very simple object whose prime purpose is to encapsulate a complex data structure for transport, or transfer, between a data provider and a data consumer. DTOs can be seen simple "lumps" of data that is structured in a complex way and cannot easily therefore be represented using primitives or value types.

DTOs:

Do not contain behaviour other than that required for their purpose of transporting data.
Do not represent objects in an application's business domain (business entities) though they may transport data that originates from / is destined for such business entities.
Can be structured in pretty much any way that suits, including heirarchically and in collections.

I've found DTOs particularly useful in situations where data needs to be transferred between systems across an interfacing layer or facade. The operations on an application's facade both accept and return data in a DTO format. DTOs help promote the decoupling of systems by allowing any complex data structures that need to be transferred to be done in a loose, independant structure that is not tied to the business domain structures of either the data provider or data consumer systems.

However, when operations on a facade need to return multiple DTOs, things can get a bit tricky. Most programming languages allow only one return value from an operation, which limits the structure of DTOs that can be returned to having one root (a single top-level DTO in the DTO structure). This is fine if the DTO structure has logically got one top-level DTO, but often this is not the case. This can pose a problem because developers will find themselves trying to manipulate the DTO structure to fit this constraint.

This is where the concept of an Exposable DTO (EDTO) steps in: The EDTO is a special DTO that is the highest-level DTO in a DTO structure. The EDTO itself does not contain any data, it simply encapsulates the complex DTO structure that needs to be transported. Using an EDTO as the root object in the DTO structure means that multiple DTOs (lists of DTOs as well as heirarchies) can be returned without the limitations of the single-return type of a program operation. This fits well with most common programming languages and paradigms today that are restricted to returning one object from an operation.

Pattern Definition

Problem	You need to transfer complex data structures using mutliple DTOs to and from independant systems.
Solution	Create an Exposable DTO as the root DTO which "wraps up" the complex DTO structure to be transferred.
Consequences	Allows facade operations to accept and return complex DTO structures without the restriction of having one top-level DTO Allows clear system interface definitions through strong typing of EDTOs Facilitates easy access to a DTO structure within an EDTO through "getter" accessopr methods on the EDTO type

UML Design

The following class diagram illustrates how the EDTOs may be designed:

UML Class model of an EDTO framework

Observations

Here are some observations I've made regarding the DTO and EDTO patterns:

DTOs are often implemented using plain-ordinary Java or .NET objects. The DTO pattern could just as easily be applied to data transferred using XML over, say, Web Services. The key difference in these implementations is that the XML requires an XML schema to describe the structure and typing of data elements in a DTO whilst implementations using a langauge like Java have typing and structure specified using the language constructs directly. Very often, I've found that DTOs defined in Java or C# will be actually be automatically translated to XML for transport from a data provider to a data consumer in order to help promote the interoperablity of systems developed using different platforms and technologies.
The EDTO pattern is sometimes badly implemented. Where Web Services return complex data, developers will often "wrap up" the data that is accepted and returned by a Web Service operation in generic "Request" and "Response" objects; the Request being an object that contains the data that is sent to a Web Service operation and the Repsonse being an object that contains the data that is returned. The problem with such generic "Request" and "Response" objects is that the typing of the parameters and return of an operation is lost. Web Services built like this will be characterised by a plethora of operations with identicle parameters and return types. These can be difficult to use and differentiate from one another because they do not explicitly declare their parameter and return data types / structures.
A good implementation of the EDTO pattern will therefore:
- Have many different EDTO types that are used as paramater and return types for operations in a facade. This means that the parameters and return types of operations are more easily distinguished from one another.
- Contain behaviour that allows consumers of the DTO structure to easily access the complex DTO data structure within. This manifests as a simple set of "get" operations on the EDTO that provide access to DTO data within.

Back to Patterns