Adam Bien's Weblog

DTO: The Exceptions From The Rule

Most JavaEE applications do not need a Data Transfer Object at all. Built-in support for JSON and XML does the transport job already. However, DTOs are still useful for special case handling like:

  1. Transferring a custom subset, superset (multiple entities) of entity data at once
  2. Dedicated optimizations like sophisticated JAXB mapping, customization of binary transfer e.g. hooks in http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
  3. Role-dependent dataset: specific roles are only allowed to see specific data attributes. However, a http://docs.oracle.com/javaee/7/api/javax/json/JsonObject.html would solve such a job perfectly as well.
  4. Client-dependent view: native clients may request a different view to data as it can be provided by stock entities. Client may require a DTO per view independently of the organization on the server.
  5. Client technology may expect different contents e.g. a JavaFX client may expect a http://docs.oracle.com/javafx/2/api/javafx/beans/property/StringProperty.html instead of a plain String.

DTOs do not have to be justified in all the use cases above. The reason for introduction is obvious: a DTO is significantly different to the persistent domain object, or the technology forces you to introduce a DTO.

[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 273 in, chapter "Data Transfer Object", particularly the strategies "Generic DTO", "Client-specific DTO"]

See you at Java EE Workshops at MUC Airport or on demand and in a location very near you: airhacks.io!


NEW workshop: HTML 5 and JavaScript Essentials, Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.

Newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

I would add:
6. Building Java API client library. Typically we have DTO as separate maven artifact which is shared by both server and client API. We don't want to use original entities because it would expose our internal DB structure (by JPA annotations).

Posted by d1x on August 28, 2014 at 10:05 AM CEST #

We were considering to get rid of DTO and JPA-Entity-to-DTO mapping but developers decided that additional mapping is worth it for the single reason - clarity. DTO do not have all the JAP/JAXB/... annotation clutter. They have clear composition boundaries: no lazy loading, extented entity managers contexts or similar. This way DTO's became part of domain write-model. l was pleasantly suprised that the very pragmatic team decided to write additional DTO-JPA mapping code just tu have clean and clean Domain entities ("DTO's").

Posted by Saulius on August 28, 2014 at 06:20 PM CEST #

And I would add:
7. Decoupling multiple UIs (like one in javascript an iphone and an android app) from your Domain model beans for various reasons. Like when using a new and unknown noSQL database in the background where you dont have lot of experience yet. I had to refactor the backend of my online motorsport manager game and i was glad that i only had to refactor the server beans and the mapping to the DTOs and nothing else!

Posted by Herbert Dowalil on August 29, 2014 at 11:36 AM CEST #

DTO and VO are required, considering to convert only few value to xml or json. and to analyse json , i use this tool http://codebeautify.org/view/jsonviewer
and to analyse XML. http://codebeautify.org/xmlviewer

I use new terme called web object. to convert required field to json/xml that would help to save bandwidth over the network and improve performance.

Posted by James Malvi on September 03, 2014 at 08:48 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
Online Workshops
...the last 150 posts
...the last 10 comments
License