A Note on Data Transfer Objects (DTO)s

  1. Data Transfer Objects (DTOs) are introduced to decouple (JPA) entities from the UI
  2. DTOs are also motivated by their typesafe nature
  3. Lacking typesafety, JSON-P JsonObjects are not used as DTOs
  4. Most DTOs are exposed as HTTP/JSON
  5. Often 3rd party libraries are used to map a DTO into a JSON
  6. Sometimes DTOs are called Value Objects
  7. The vast majority of DTOs remains identical to entities over the entire lifecycle of a project
  8. Copying data between DTOs and entities requires series of getter-setter invocations
  9. DTOs are growing, the mapping logic is extracted into dedicated "mappers"
  10. DTOs and mappers introduce a significant amount of untested code, which disturbs the code coverage statistics
  11. Getters and setters, constructor tests are written to increase the code coverage
  12. Now: structural JPA entity code changes, affect DTOs, mappers and the corresponding unit tests
See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.


So what's your conclusion? Avoid DTOs as long as they aren't necessary?

Posted by Alex on October 10, 2018 at 09:31 AM CEST #

Point 10, 11: usually DTOs should be omitted from code coverage. Writing tests for this purpose is nonsense

Posted by Tino on October 12, 2018 at 04:35 PM CEST #

The Great advantage however is that nobody accidentally breaks the api when updating the Data Model.

Posted by Philipp on October 16, 2018 at 06:05 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments