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?
asked Oct 26, 2012 at 5:27
-
11But POJO can be DTO and DTO can be implemented with POJO. You are comparign apples and oranges.– EuphoricOct 26, 2012 at 5:48
-
3Why 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.– GiorgioOct 26, 2012 at 5:59
-
There is no point, it's an anti-pattern, see: Data Transfer Object Is a Shame– yegor256Jul 18, 2016 at 1:45
Add a comment
|
6 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.
DTO's are a fundamental concept, not outdated.
-
14you may find them under different names though, since everyone seems to be reinventing the wheel these days– linkerroOct 26, 2012 at 10:25
-
4
-
4@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.– GiorgioNov 1, 2012 at 10:36
-
13@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. Jun 4, 2013 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.
answered Oct 26, 2012 at 10:25
-
3As 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? Jun 4, 2013 at 22:39
-
5@ErikReppen The main benefit is decoupling your domain models & DTO's. If your DTO maps itself, it needs a reference to your domain models. Jan 3, 2019 at 22:20
-
1DTOs are very useful in APIs. If you simply return the internal model to the client, they may have all your info (e.g., a user's address, email, government identifier, phone number, etc.). With a DTO, you map the info they need and only that info. Also, if you add one of these properties to a shared domain/DTO later, it is sent to the client by default. You have to add code to make the field not get returned, which is worse (from a security standpoint) than accidentally NOT returning a field.– ps2goatDec 31, 2019 at 19:30
Although DTO is not an outdated pattern, it is often applied needlessly, which might make it appear outdated.
From Java guru Adam Bien:
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
From Martin Fowler:
DTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls. They are part of implementing a coarse grained interface which a remote interface needs for performance. Not just do you not need them in a local context, they are actually harmful both because a coarse-grained API is more difficult to use and because you have to do all the work moving data from your domain or data source layer into the DTOs. ~ Martin Fowler
Here is a Java EE specific example of a common but incorrect use of the DTO pattern. If you're unfamiliar with Java EE, you just need to know the MVC pattern: a "JSF ManagedBean" is a class used by the View, and a "JPA Entity" is the Model in the MVC pattern.
So, 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.
Futhermore, consider Bean Validation annotations (again, if you're unfamiliar with Java EE, know that Bean Validation is an API for validating data). 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:
-
6There'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...– KawuDec 21, 2017 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 AvalosMar 12, 2018 at 4:10
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.
-
Instead of copying data from Object A to Object B, you can create method toJson() in object A and set nulls to fields you don't want to expose. If you have multiple endpoints for different fields, you can use toJsonXXX() where XXX is the use-case– XokeMar 4, 2020 at 18:18
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.
DTO is really powerful. One use is to compose data from multiple objects to be transported. The second use is to hide your data object details away from the rest of the application and this can give you the ability to change the data objects. For example if you were using mysql database then you changed to mongodb your data object can change as result. to avoid the change in the rest of your application you can use DTO and then just change the mapper using dependency injection to avoid such change.
