I have a composite Dto, where properties are primitive values or other Dtos (that occurred in many places).
Eg :
- PersonDto
- Name
- Surname
- AddressDto
- Street
- Number
- ContactDto
- PhoneNo
In this example AddressDto and ContactDto are used in many other Dtos (not only PersonDto), so i am tempted to add some business logic to those Dtos. In particular i would like to add update logic to those Dtos (eg: define an IUpdateable interface) to handle how the Dtos persist information.
In that way when i have to deal with a Dto i can check if it's a composite one, and in the case i know i can rely over IUpdateable children Dto contained in the parent Dto to get the "right update logic".
But i have the feeling this is not the correct way to proceede, Dtos (as name imply) shuld carry only information and no business logic. I don't like the idea to start attach logic to Dto also because then i am constrained to that specific logic (if i need a ContactDto with that exact structure but different update logic, my only option is to derive a new type..and this seems ugly)
That said, so far, i have indulged, in use interfaces over Dtos only if the interface is merely a "tag" that describe the "scope" of the Dto; and in that sense guarantee the fact that Dto will contain some properties with a specific meaning.
But now it's not clear to me how to achieve two goals :
- i would like to "tag" the Dto to make explicitly clear that the Dto can be used in some functionality (eg : as in the previous example that the Dto can be in some way stored)
- i would like to make it clear and "incapsulated" the logic that will handle the Dto functionality (the way to store the Dto)
Optionally i would like to achieve the goals above in the simplest way without too complex artchitecture