Transfer Object (TO)

ARCHITECTURAL Role

This pattern is unrestricted; it is used within any architectural layer.

BEHAViOR DEFINED

A PED Transfer Object (TO) supports an impedance mismatch and/or performance optimization. In years prior to persistence technology a challenging impedance mismatch often occurred between objects and database tables.

Contemporary applications may have an impedance mismatch between a JAX-RS service and a Domain Entity (DE). Once again the TO pattern is being called upon to encapsulate business data. For example, a TO may contain a subset of DE fields reducing the ‘weight’ of an instance. The ‘weight’ reduction contributes to enhanced messaging performance (fewer bytes pulled across the ‘wire’) and/or scalability (fewer bytes cached). 

Unlike a DE, a TO typically does not have a unique identity. In addition, provider TO variants may have declarative validation rules (JSR 303) that are a subset of rules on a DE. Real-world request validation is a technical nuance that may, by itself, eliminate a provider from directly using a DE with JAX-RS. Of course, consumer (or client) applications do not have the option of using a DE.

When using a TO in a RESTful provider context, consider these suffix variants for expressive readability:

  • …RequestTO
  • …ResponseTO
Structural Characteristics

Characteristic

Recommended

Note

 Extend Base Class Y  
 No-arg Constructor Optional  
 CDI Scoping N  
 Instance State Y  
 Static Public Methods (enum) N  
 Fluent Methods Y  
 Delegate to Helper N  
 Worker-thread Safe Typically  
Source Example