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.
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
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.