How evil are Data Transfer Objects (DTOs)?
DTOs aren't dead. The opposite is true. In certain situations, they become the necessary tool or workaround to solve a particular problem. Impedance mismatch between layers is rather common. The object driven JPA (entity/domain layer) is often kept DRY and fluent, whereby the database driven approach results in anemic domain objects. In either case you would like to keep your exposed REST-API simple and lean. Some relations are probably going to be collapsed, attributes renamed and even types changed. E.g. storing java.util/sql.Dates in a database might be o.k., but it doesn't have to be serialized directly into JSON / XML - sometimes a simple String or int does a better job.
It is perfect valid to introduce a dedicated DTO to adapt an incompatible domain layer. It is much better, than changing the domain layer to the needs of a particular client. Then your domain layer will become dependent on the particular client. ...and in long term this approach will hit the maintainability.
On the other hand considering a dedicated DTO layer as an investment, rarely pays off and often lead to over-engineered and bloated architectures. At the beginning the DTOs will be identical to your domain layer - without any impedance mismatch. If you are "lucky", you will get few differences over the time. Especially with lightweight platforms like Java EE 6, the introduction of a DTO is a bottom-up, rather than top-down approach. Exactly like it is the case with DAOs.
Substantially more important for the maintainability is a single, dedicated, canonical layer. You have to commit your efforts either to the database (or XML-schema etc.) or your domain objects and derive everything from that. In best case even generate all "throw-away" artifacts from your clean, canonical representation.
[see page 153 and 253 in "Real World Java EE Patterns - Rethinking Best Practices" book]
Your last sentences hit a delicate topic ... could you elaborate what you think would be a sensible approach for "deriving throw-away artifacts" from your "dedicated,canonical layer"?
Are you suggesting code-gen or even an MDSD approach?
Posted by Jonas Bandi on August 05, 2009 at 12:45 PM CEST #
@Jonas,
I would start a POC with Velocity or Freemarker to find out how it works. It should not take longer than 2 days for the whole procedure. In case it works well - you are done. If not you can try "heavier" MDSD tools, but you already gained some experience and will be even able to reuse the templates...
thanks for your comment!
adam
Posted by Adam Bien on August 05, 2009 at 01:00 PM CEST #
@Jonas,
I'm a big fan of MDSD (e.g. eclipse.modeling.tmf). You are able to define your own dsl. Generation of certain artifacts like entities and dtos is than easy possible.
From my point of view, I wouldn't do any larger project without the help of generation
Posted by Martin on August 05, 2009 at 03:00 PM CEST #
@Martin,
1. eclipse's EMF, GMF + oaw ARE great.
2. Java EE 5/6 is so lean, that you can do a lot without generation. Even very large projects...
Thanks for your comment!,
adam
Posted by Adam Bien on August 05, 2009 at 04:39 PM CEST #
@Adam
From my point of view, it depends on the project.
e.g. when I have a (classical) layered project I would always do the generation approach.
(and with the eclipse tools today you are really fast to establish it...)
Generally the modelled information are in most cases reusable for much more than one application part.
Because of the known advantages of MDSD it is especially in large projects a good approach (documentation / enforcement of a certain well known architecture and so on...)
Martin
Posted by Martin on August 05, 2009 at 06:57 PM CEST #
@Martin,
it is really hard to say. The success of MDSD is also dependent on the developer's acceptance. It also depends on the project context, your outsourcing strategy etc.
You can be very efficient in Java EE 5/6 development only with vi or emacs (if you know these tools :-))
thanks for the nice conversation!,
regards,
adam
Posted by Adam Bien on August 05, 2009 at 09:33 PM CEST #
I really enjoyed your discussion. I have been working in large IT-projects since 2004 and I don't like the mdsd approach. Why? Because I love lean architectures. In J2EE, I agree there was the need to generate j2ee infrastructure code, but in JavaEE everything on the back end tier has become so easy. If architects would finally start to rethink, developing would be much easier and more maintainable...
Greetings
Daniel
Posted by Daniel on August 06, 2009 at 01:32 AM CEST #
@Daniel
Of course it depends on the project.
But imagine a project with classical backend structure and a "Rich Client" (GWT / Swing / Eclipse RCP ) in which the client communicates over the network (or a project which have to serve more than one UI technology e.g. mobile devices).
You have to provide additional communication layers and dataformats to communicate.
Out of a model (and I prefer a textual model which fits nicely in todays development tools) you are so easy to generate a bunch of artifacts.
E.g. Based on your model you are able to generate parts of the UI (maybe for different client technologies) because you have (mostly) the definitions in your model without a binding to a certain technology and reuseable. Many parts of your app (layers, communication, databinding, mapping) and so on are generateable.
You are easier able to enforce certain rules / standards of development. And from my point of view you can shield a certain amount of complexity from new (or not so experienced) developers.
Martin
Posted by Martin on August 06, 2009 at 10:09 AM CEST #
I think that for the "Date" case isn't a bad idea to add a @Transient method that transform a Date to Int. Without requering the use of a DTO. What you think?
Posted by juan77 on August 06, 2009 at 10:51 PM CEST #
@Juan77,
it really depends whether it is an exception or a common case.
@Transient attributes shouldn't blur the expressiveness of a domain object. Otherwise your code will not only become complex, but also very brittle.
thanks!,
adam
Posted by Adam Bien on August 06, 2009 at 11:31 PM CEST #
For Date to String convertion I use @XmlJavaTypeAdapter annotation with an implementation of XmlAdapter.
I found DTO's usefull for my current project as I have to confirm my WS to a 2 different public standard.
Posted by Daoud AbdelMonem Faleh on August 10, 2009 at 04:55 PM CEST #
do u know Evans DDD? Do u Know MDD?
what is DDD? One Domain Model, No DTO, No Presentation Model.
Posted by banq on August 17, 2009 at 01:34 PM CEST #
>Then your domain layer will become dependent on the particular client
this can be done by DDD's VO(Value Object), no need DTO.
Posted by banq on August 17, 2009 at 01:36 PM CEST #
@Banq
>this can be done by DDD's VO(Value Object), no need DTO.
I cannot agree with this point
see: http://www.adam-bien.com/roller/abien/entry/value_object_vs_data_transfer
Posted by Adam Bien on August 19, 2009 at 12:35 PM CEST #
Nowadays people use DTO for REST/WebServices/Messaging integration stuff, DTO help isolate Domain from this various models and it's a good idea because the lifecycle of integrations projects are not the same as the core business layer...
Posted by smelaatifi on August 18, 2014 at 10:00 AM CEST #
I dont like exposing my Domain via REST, or anything else. The Domain contains information to the layout of my data, exposing it is violating encapsulation - If you have more than a couple of clients, you'll never be able to change your domain again.
Instead, always put a DTO layer infront of the domain - and the DTO should be modeled on exactly what the client wants...so the client can easily get the data it needs with minimal requests to the server.... If doing a javascript rendered webapp, The DTO could ideally represents the a single page, so the client just gets a single DTO, and populates. Very fast, efficient. The same DTO can be use to send to a mobile app, because more than lightly the mobile app's equivalent page will contain the same data, just formatted differently.
Posted by Tony Weston on September 08, 2015 at 10:51 AM CEST #