Take the 2-minute tour ×

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
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
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
add comment

3 Answers

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.


Are Data Transfer Objects an out dated concept?

No, since DTO is a fundamental concept.

share|improve this answer
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". –  Shuvo 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
add comment

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
add comment

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
add comment

Your Answer


