1

In a project I inherited, on many occasions, there are classes named as XyzDataObject. Although called DataObject, they mostly look to me like what I usually refer to as a Data Transfer Object (DTO). They have some specialties to them however:

  • Used in a an area, where only a subset of the domain data is used (good)
  • Consist mainly of standard typed properties (fine)
  • Super-minimal logic for instantiation (ok)
  • Mapping functions from and to the Domain Objects (oops?)

Now it is my understanding from this answer, that these mapping functions should be separate.

Question:

  • Is the mapping feature the reason these objects might be called "Data Objects" instead of Data Transfer Objects?

Or:

  • Is this just a naming issue and they should be called DTO's anyway?
  • Should the be named something else altoghether because of their mapping capabilities?
Marcel
  • 15,039
  • 20
  • 92
  • 150
  • 1
    In my humble opinion, this boils down to a subjective naming issue. However, I would argue that a DTO should contain no logic whatsoever, including constructors. I suppose it depends on whether we're talking about a public API or a back-office system and what conventions your team have used in the past. – Chris Pickford Jun 24 '19 at 12:28
  • 1
    IMHO it's a design flaw, since DTOs should not have mapping capabilities themselves and Mappers should not be part of the entity they map. Mistakingly calling the classes you described "DataObjects" only creates confusion, as they simply appear to be a lazy blending of DTOs and Mappers. – StackLloyd Jun 24 '19 at 12:40

0 Answers0