I am in the middle of starting up a new project and just wanted some reassurance as to which approach to DTO's returned by the read-side was easier to maintain in a real world application with reasonable complexity.

I realize with a DTO per query, it would allow for a specific query's response to diverge from the others more easily in the future. However, common properties between that query and other queries would require changes in multiple places (e.g. the same resource could have multiple queries in the form of GetById, GetAll, GetByStatus, GetBySomethingElse, etc.) and there is more repetition.

If a DTO is created per representation of a resource, a GetById might return a DetailedDto with many properties, while a GetAll might return a SummarizedDto with fewer properties. This would require less changes for common properties and diverging queries would just require a new version of the DTO to be created. The biggest disadvantage to this approach is that I'm terrible at naming classes and coming up with words, so "Detailed" + "Summarized" is the extent of my imagination.

I'm leaning towards refactoring my first attempt at writing this application from using the "DTO per query" to the "DTO per representation" approach. Are there any benefits to sticking with the "DTO per query" or is "DTO per representation" a good way to go?

  • You can't follow a strictly "DTO per representation" approach. How would you return an Invoice object without a DTO that's customized? Jul 16, 2019 at 15:10
  • @robert-harvey I think the question is: “is it ok if multiple requests for the same entity share a response object?” So a GetFileById request returns a FileDto; a SearchFilesByName returns a list of the same FileDto and GetLastGeneratedFile also returns the same FileDto. In my opinion it’s fine if all request handlers fill all properties of the Dto; I prefer Dto’s with a single constructor without setters.
    – Rik D
    Jul 16, 2019 at 17:29
  • Hm. Why wouldn't it be OK? Jul 16, 2019 at 18:06


Your Answer

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

Browse other questions tagged or ask your own question.