This pattern is unrestricted; it is used within any architectural layer.
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:
|Extend Base Class||Y|
|Static Public Methods (enum)||N|
|Delegate to Helper||N|