Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What is the point of using DTO and is it an out dated concept? I use POJOs in the view layer to transfer and persist data. Can these POJOs be considered as an alternative to DTOs?

share|improve this question
3  
But POJO can be DTO and DTO can be implemented with POJO. You are comparign apples and oranges. –  Euphoric Oct 26 '12 at 5:48
1  
Why should good ideas become outdated? Look at Lisp. Apart from jokes, I agree with Euphoric: I normally implement DTO's using POJO's. I still find DTO's are very simple (KISS) and useful concept. –  Giorgio Oct 26 '12 at 5:59

4 Answers 4

DTO is a pattern and it is implementation (POJO/POCO) independent. DTO says, since each call to any remote interface is expensive, response to each call should bring as much data as possible. So, if multiple requests are required to bring data for a particular task, data to be brought can be combined in a DTO so that only one request can bring all the required data. Catalog of Patterns of Enterprise Application Architecture has more details.

EDIT

Are Data Transfer Objects an out dated concept?

No, since DTO is a fundamental concept.

share|improve this answer
1  
you may find them under different names though, since everyone seems to be reinventing the wheel these days –  linkerro Oct 26 '12 at 10:25
    
Like "Value Object". –  IAmTheDude Oct 26 '12 at 10:53
    
@linkerro: True: I think lots of people should spend more time reading about stuff that has already been invented instead of re-inventing it themselves. Re-invented stuff will always be less mature. –  Giorgio Nov 1 '12 at 10:36
    
@Giorgio There's a lot of devs out there still running with ideas that should have never made it off the ground. I wish more devs questioned every idea they read about. –  Erik Reppen Jun 4 '13 at 22:41

DTO as a concept (objects whose purpose is to collect data to be returned to the client by the server) is certainly not outdated.

What is somewhat outdated is the notion of having DTOs that contain no logic at all, are used only for transmitting data and "mapped" from domain objects before transmission to the client, and there mapped to view models before passing them to the display layer. In simple applications, the domain objects can often be directly reused as DTOs and passed through directly to the display layer, so that there is only one unified data model. For more complex applications you don't want to expose the entire domain model to the client, so a mapping from domain models to DTOs is necessary. Having a separate view model that duplicates the data from the DTOs almost never makes sense.

However, the reason why this notion is outdated rather than just plain wrong is that some (mainly older) frameworks/technologies require it, as their domain and view models are not POJOS and instead tied directly to the framework.

Most notably, Entity Beans in J2EE prior to the EJB 3 standard were not POJOs and instead were proxy objects constructed by the app server - it was simply not possible to send them to the client, so you had no choice about haing a separate DTO layer - it was mandatory.

share|improve this answer
    
As a UI dev forced into a more generalist role I've definitely found the Mapper.Map phenomenon in our codebase stupifying. Why can't the DTO just map itself? –  Erik Reppen Jun 4 '13 at 22:39
    
+1 For a good and through explenation –  Priidu Oct 8 at 17:14

Absolutely not! Just recently I had my lessions learned about better using DTOs rather than your business object you use (possibly bound to your ORM mapper).

However, just use them when they're appropriate to use and not just for the sake of using them because they're mentioned in some good pattern book.
A typical example which just comes to my mind is when you expose some kind of interface to 3rd parties. In such scenario you'd like to keep the exchanged objects quite stable which you can usually achieve nicely with DTOs.

share|improve this answer

Although DTO is not an outdated pattern, it is often applied needlessly, which might make it appear outdated.

The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). ~ Adam Bien

For example, say you have a JSF ManagedBean. A common question is whether the bean should hold a reference to a JPA Entity directly, or should it maintain a reference to some intermediary object which is later converted to an Entity. I have heard this intermediary object referred to as a DTO, but if your ManagedBeans and Entities are operating within the same JVM, then there is little benefit to using the DTO pattern.

Consider Bean Validation annotations. Your JPA Entities are likely annotated with @NotNull and @Size validations. If you're using a DTO, you'll want to repeat these validations in your DTO so that clients using your remote interface don't need to send a message to find out they've failed basic validation. Imagine all that extra work of copying Bean Validation annotations between your DTO and Entity, but if your View and Entities are operating within the same JVM, there is no need to take on this extra work: just use the Entities.

IAmTheDude's link to Catalog of Patterns of Enterprise Application Architecture provides a concise explanation of DTOs, and here are more references I found illuminating:

share|improve this answer

protected by gnat Dec 16 at 22:15

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.