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

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 conv开发者_如何学Cersion 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?

I'd think the name would give away the intent: Data Transfer Object. Data Transfer.

The idea behind DTO's is that you use them to encapsulate data that you're sending outside of your domain model, to another layer for example. You're not exposing your logic, you're just sending some data.

If your domain objects are DTO's, either you're exposing your domain logic outside of your domain model, or you're keeping your domain logic somewhere other than in your domain objects. Or both.

I've been on projects that kept them separated and I've been on a project that blended them. I really can't recommend blending them. Your layers start to blend, like tie dye.

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.