128

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?

  • 10
    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
  • 3
    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
  • There is no point, it's an anti-pattern, see: Data Transfer Object Is a Shame – yegor256 Jul 18 '16 at 1:45
112

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.

DTO's are a fundamental concept, not outdated.

  • 9
    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
  • 3
    Like "Value Object". – theD Oct 26 '12 at 10:53
  • 2
    @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
  • 10
    @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
56

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.

  • 2
    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
    @ErikReppen The main benefit is decoupling your domain models & DTO's. If your DTO maps itself, it needs a reference to your domain models. – Alexander Derck Jan 3 at 22:20
16

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:

  • 3
    There's the sentence: "..., but if your ManagedBeans and Entities are operating within the same JVM, then there is little benefit to using the DTO pattern". There are many medium-sized apps in companies out there which stupidly implement the DTO pattern without any benefit. It just adds a useless "copy layer". The people who created these systems didn't realize the Java EE 5+ entity manager detaches the entities when the transaction ends and makes them the actual DTOs. So, for single-JVM webapps, the pattern kind of is outdated. It seems to be the J2EE backend developers' relic... – Kawu Dec 21 '17 at 15:09
  • But what is a "JSF ManagedBean" and a "JPA Entity"? If they're not outdated, then you should be able to explain them using framework and language agnostic terms. – U Avalos Mar 12 '18 at 4:10
8

Absolutely not! Just recently I learned lessons 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.

0

One place I've found DTOs to be especially useful is in containing logic for API responses. With this pattern it's easy to manage different types of responses from objects to various formats in a testable manner. Using this pattern at my current role we were able to start testing the response formats for our APIs which has been valuable since our stack is becoming more isomorphic with various clients (http/mobile). Definitely not outdated.

protected by gnat Dec 16 '14 at 22:15

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

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.