Code Smell 40 - DTOs
Data Transfer Objects (DTOs) are widely used, and they 'solve' real problems, do they?
Information Hiding Violation
Transfer anemic data on arrays.
Use real business objects.
If we want to transfer partial objects: use proxies or null objects to break the reference graph.
We can use the same anemic object detectors.
We can check for anemic classes with no business object behavior (removing serializes, constructors, mutators etc).
DTOs are a tool and an established practice in some languages. We should use them with care and responsibility.
If we need to disassemble our objects in order to send them away from our realms, we need to be extremely cautioned. Since dismembered objects have no integrity considerations.
His author warns us about its actual abuse.
The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class.
This article is part of the CodeSmell Series.
Hi Maxi, thanks for sharing your though on the subject. I have to say, I do not agree with your analysis on the DTOs for the following reason: 1) In the list of Problems you mention the following
- Anemic object: Well DTOs are object in the sense they are instance of a class BUT their purpose is not to provide any other feature than transporting information. NOT logic. As such their roles is to serve as projection of data. They are containers. This would be like saying a Tuple is anemic....
- Inconsistent data: From what angle? They are not suppose to be the source of any data. they are suppose to be used to transport data.
- Duplicated Logic: They cannot have any logic. They are object but they should be immutable. They are simply a tool to model parameters in an API. They should not be confused to Value Object...
- Duplicated Structure: Again they are there to serve as container with predefined structure. They no not represent "Entities" or "Value Object". They are used to transfer data between one system, world, model.. to another...
- Class poluting: I do not understand that point. You will probably model them using a class. Do you mean poluting the entities of your model? Then again they should not be part of your model as such... They are part of the contract or the api your model expose. as a mean to structure the API of your model for example...)
I will not comment on every point of your assumptions as I believe their were listed based on an wrong use of the DTOs.
My point is DTOs are predifined tuples. No logic. Just a tool to define a projection of your famous "object". If you start adding logic on them then I guess you are building something closer to a Value object or ADTs in FP. When building API (Not limited to inter system api but also apis for other "objects" they are pretty handy to structure this API.
thanks again for sharing your view.
Hi Maxi Contieri, indeed, I guess your point make sense in this particular programming paradigm. I can understand your point when talking about Employee class, EmployeeDTO, EmployeeDAO and in a classic OO multi tier application. Functional Programming have a different usage of DTOs and serve at the foundation of their Algebraic Data Types. They are no code smell at all in this context :p
Alexandre Roba I love F.P. purity.
I wish we had their immutability, no side effects, high order functions and many more of its elegance.
But I don't have actual experience on FP, so I cannot talk about DTOs on an FP context.
My articles are related to OOP where I have some experience and cannot discuss other paradigms.