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