Is it good practice to have DTO objects deepy integrated in code?

Question

I'm building a fairly large application that makes use of the DAO/DTO design pattern to obtain data from a database. In the application a particular DTO has become the "core data structure" in that it's referenced all throughout the project. I'm wondering if it is a good practice to have this DTO so deeply integrated throughout the project, or should I have some kind of conversion layer where I convert the DTOs into non-DTO objects?

I can see reasons for and against having this conversion layer. For example, if we do have the conversion layer then: 1) Drastic changes to the DTO may cause errors throughout the project, hence having the conversion layer isolates the error to a single point in the code. 2) I am able to add additional logic to the core data structure which cannot be added to the DTO because it is auto-generated.

However I see drawbacks to having a conversion layer too: 1) The DTO Conversion code must be kept consistent whenever the DTO changes. This adds another step that the programmer must be aware of and hence is more error prone. 2) This also leads to code duplication since, for the most part, you are copying the accessors of the DTO.

What's the best route to go? DTOs every where or a conversion layer? Can anyone out there guide me in the right direction?

Answer 1

I'd consider DTO to be something of an anti-pattern, a relic from a time when EJB 1.0 persistence was so chatty that DTOs were necessary to cut down on the network traffic.

Now I would say create model objects and sleep at night. Make them immutable if you can and don't worry about DTOs.

Translations for the sake of architectural purity wastes CPU cycles without providing much value.