Comment by Alexandre Roba on "Code Smell 40 - DTOs"

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.

Alex.

Hi Alexandre Roba, thank you very much for your comments. We agree they are as anemic as tuples or structs. So, why should they exist in an OOP world?

They are handy if we get used to duplicating object and treat them as data. I don't like any of them.

Most of the smells are related to handy solutions that generates duplication and coupling.

Since many languages favor this kind of solutions, and we are eager to change languages we are fine with this state-of-the-art.

My point with many code smells is: we deserve to build better tools. Less handy but more engineering ones.

If you learned something new from Employee domain you should change just a single point (probably employee class). This is DRY principle. Changing Employee class, EmployeeDTO, EmployeeDAO etc, is error prone. If you need to transfer and Employee, just transfer and Employee. Not an anemic duplicated tuple.

Search Hashnode