0

It might be that my question would sound a bit stupid but I would like to find the best way for naming my DTO interfaces. In my PHP application I have following DTO types:

  • Simple (which contains a list of properties), for example CredentialsDTO, PhoneDTO, AgreementDTO.
  • Array-like (which contains an array of single-type DTOs, any of these three), for example AgreementsDTO which contain some AgreementDTO.
  • Complex or Nested (which contains a few other DTOs, either simple, array-like or complex/nested), for example AccountDTO (which contains CredentialsDTO, PhoneDTO, AgreementsDTO).

I would like to create an interfaces for these three types but I don't really know how to name them.

OK, the first one might be just a DTOInterface, for me it sounds clear, array-like is more complicated, ChatGPT offered me DTOCollectionInterface or DTOListInterface but from my perspective collection MUST have data manipulation methods and list... I don't really understand how them differ from arrays.

Talking about complex/nested, I think anything is fine so I just wanna know which one is standard-to-use.

Thanks in advance!

Improve this question
5
  • 2
    The purpose of a DTO is to be a simple bag of information with no logic. Why define an interface at all?
    – Greg Burghardt
    Commented Sep 3 at 13:40
  • @GregBurghardt Wikipedia: The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage, retrieval, serialization and deserialization of its own data (mutators, accessors, serializers and parsers).
    – Viacheslav Ravdin
    Commented Sep 3 at 13:43
  • And I know this part is idiomatic for PHP, but it drives me absolutely bonkers that the PHP community wants you to put "Interface" in an interface. The "I" prefix for C# is sufficient if you need a naming convention.
    – Greg Burghardt
    Commented Sep 3 at 13:47
  • @GregBurghardt completely agree.
    – Viacheslav Ravdin
    Commented Sep 3 at 16:42
  • 1
    @ViacheslavRavdin: How does your Wikipedia definition counter Greg's (first) point? Because I don't see how it does. While we can argue whether trivial mapping logic counts as "logic" semantically, what use case are you foreseeing for different implementations of the same DTO interface? DTOs follow the same principle as pure function in that they are deterministically testable, have no hidden side effects, and therefore can be used without abstraction (on the premise that they are backed by an appropriate test suite of their own for any logic contained within them).
    – Flater
    Commented Sep 4 at 1:59

1 Answer 1

Reset to default
0

I can't speak to any PHP specific parts of this question (there may be naming standards I am not aware of).

However typically you would use concrete classes for DTO's since you are effectively saying this object is a "bag" of properties representing a real world thing. That's not to say you couldn't implement an interface on your DTO's for example IHasIdentity which provides a get_id() method and this might be something you would want all your DTOs to implement.

Going through your examples:

Simple (which contains a list of properties), for example CredentialsDTO, PhoneDTO, AgreementDTO.

I would typically just name these Credentials, Phone, etc in that I would put them in a package that indicated they were DTOs, but keep the class names clean. However as I noted at the beginning, the PHP community may have strong feelings about pre/postfixing with the words Interface or DTO.

Array-like (which contains an array of single-type DTOs, any of these three), for example AgreementsDTO which contain some AgreementDTO.

I question the need for these types of object in a DTO context. The two cases I have typically seen are either:

  • A parent object such as person having a list, map or set of phones.
  • A wrapper used in HTTP responses.

In the first case the name of the DTO would be based on the type of the parent; Person in this case.

In the second case I would either use a generic "pagination" wrapper that provides additional metadata fields such as current page number and total number of pages or if that is not an option in a particular language, I would create multiple classes clearly named as wrappers: AgreementPaginationWrapper or maybe AgreementPageResponse

Complex or Nested (which contains a few other DTOs, either simple, array-like or complex/nested), for example AccountDTO (which contains CredentialsDTO, PhoneDTO, AgreementsDTO).

As noted/hinted at above I don't see this a special case - whether a DTO is a single object or consists of multiple objects in a hierarchy, naming is still based on the function at that level.

However I will call out one special case, which is DTO's should typically be tied to bounded contexts in that an Order may be tied back to the Person that created it. In this case we are likely changing context, as a result I would only include a reference (ID) to the Person in the Order not the whole DTO.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.