I've recently overheard people saying that DTOs are an anti-pattern. Can someone please explain why? What are the alternatives?
+2
A:
OO purists would say that DTO is anti-pattern because objects become data table representations instead of real domain objects.
Darin Dimitrov
2009-09-17 19:52:18
+1
A:
I think the people mean it could be an anti-pattern if you implement all remote objects as DTO's. A DTO is merely just a set of attributes and if you have big objects you would always transfer all the attributes even if you do not need or use them. In the latter case prefer using a Proxy pattern.
jdehaan
2009-09-17 19:52:30
+6
A:
Some consider DTOs an anti-pattern due to their possible abuses, they're often used when they shouldn't be/don't need to be.
This article vaguely describes some abuses.
Ben S
2009-09-17 19:53:45
The article much more accurately describes DTOs as a pattern which can be abused.
Craig Stuntz
2009-09-17 19:57:37
+5
A:
DTO an AntiPattern in EJB 3.0 says:
The heavy weight nature of Entity Beans in EJB specifications prior to EJB 3.0, resulted in the usage of design patterns like Data Transfer Objects (DTO). DTOs became the lightweight objects (which should have been the entity beans themselves in the first place), used for sending the data across the tiers... now EJB 3.0 spec makes the Entity bean model same as Plain old Java object (POJO). With this new POJO model, you will no longer need to create a DTO for each entity or for a set of entities... If you want to send the EJB 3.0 entities across the tier make them just implement java.io.Serialiazable
aem
2009-09-17 19:54:23
+5
A:
I don't think DTO's are an anti-pattern per se, but there are antipatterns associated with the use of DTO's. Bill Dudney refers to DTO explosion as an example:
http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf
There are also a number of abuses of DTO's mentioned here:
http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/
They originated because of three tier systems (typically using EJB as technology) as a means to pass data between tiers. Most modern day Java systems based on frameworks such as Spring take a alternative simplified view using POJOs as domain objects (often annotated with JPA etc...) in a single tier... The use of DTO's here is unnecessary.
Jon
2009-09-17 19:54:32
+7
A:
Some projects have all data twice. Once as domain objects, and once as data transfer objects.
This duplication has a huge cost, so the architecture needs to get a huge benefit from this separation to be worth it.
KLE
2009-09-17 19:54:53
Please elaborate on the "huge cost". Also, say why the cost can't be eliminated by using code generation techniques to generate the DTO classes.
John Saunders
2009-09-17 20:05:20
+1. Twice? Only if you're lucky :-) Projects that duplicate domain entities as DTO also tend to have almost-the-same-but-oh-so-subtly-different UI beans to complement them. That's 3. And if, god forbid, there's some sort of remoting (web services / xml-rpc / whatever) going on, you can easily get to 4 or 5.
ChssPly76
2009-09-17 20:20:26
Let's see the first cost is converting them from the domain object to the DataDto. Then you convert the DataDto to a WebDto (or a UiDto), for the second cost.Then later on down the road, you have to add a field. So you have to add the field to the domain and 2 Dtos, and the conversion routines.Since very often WebDtos are all strings, now you have to do some calculations on a number field. So now you have to change the WebDto, and it's conversion routine. There's another cost.So you have costs in development time, debugging time, and of course the overhead of the conversions.
Jim Barrows
2009-09-17 22:48:34
I am currently working with a enterpricy 14 layer lasagna architecture (NOT KIDDING). I can assure you that the 11-or so layers that is mainly for data-transer does not come for free.
KarlP
2009-09-18 07:15:48
Also, while I absolutely love code generators when working with stupid designs, they are a) a sure thing that you are doing it wrong to begin with. b) they do not come for free.
KarlP
2009-09-18 07:17:08
@John By costs, I mean development time, and runtime object creation and copies. I agree, development time could be alleviated by code generation techniques, if well-mastered ... but they sometimes have problems on their own.
KLE
2009-09-18 07:31:23
@Karlp thanks for you real-life input. Your situation seem incredible. Is there a place where you could give us more details (maybe something more readeable that some comments?).
KLE
2009-09-18 07:33:24
+11
A:
DTOs are not an anti-pattern. When you're sending some data across the wire (say, to an web page in an ajax call), you want to be sure that you conserve bandwidth by only sending data that the destination will use. Also, often it is convenient for the presentation layer to have the data in a slightly different format than a native business object.
I know this is a java-oriented question, but in .Net languages anonymous types, serialization, and linq allow DTOs to be constructed on-the-fly, which reduces the setup and overhead of using them.
Gabe Moothart
2009-09-17 20:00:19
I'm going to have to downvote this answer because of your mention of serializing anonymous types. You can't even _return_ an anonymous type, much less serialize it in the same way you could serialize a DTO.
John Saunders
2009-09-17 20:06:36
@John, This is incorrect. I do it all the time. Serialization uses reflection, which works just fine on anonymous types. Just pass it to the serializer as an object. And once it is serialized (to xml or json, for example) of course you can return it from a method.
Gabe Moothart
2009-09-17 20:24:09
Um, John, that's just not true. You can serialize anonymous types to JSON just fine. Try it in an MVC app:return Json(new { Foo = "Hi there! } );I promise you it works just fine. Better, perhaps, than non-anonymous types, since anonymous types generally have no cycles in their object graphs, which break the JSON serializer.
Craig Stuntz
2009-09-17 20:24:56
Json serialization is not a DTO in this sense, and therefore doesn't apply.Then of course, my arguments above apply as well, at some point, they just stop being worth it.
Jim Barrows
2009-09-17 22:50:38
+2
A:
If you're building a distributed system, then DTO's are certainly not an anti pattern. Not everyone will develop in that sense, but if you have a (for example) Open Social app all running off JavaScript.
It will post a load of data to your API. This is then deserialized into some form of object, typically a DTO/Request object. This can then be validated to ensure the data entered is correct before being converted into a model object.
In my opinion, it's seen as an anti-pattern because it's mis-used. If you're not build a distributed system, chances are you don't need them.
Bealer
2009-09-18 00:10:03