We are building an pseudo-rest API (because no body cares/funds for a full blown rest API for internal use - which is OK).

So we have elements of Rest API (links for resources, API naming conventions and standardized output data model following some naming conventions in google json standards).

But because of this Our output DTO will be different from the entities - and now we are churning a lot of DTO classes since we provide a lot of summary api (remember pesudo-rest) as per business needs.

I have done a lot of research and lot of them are not looking enticing options. Please share from your experience if what we are doing is fine (lot of DTO classes).

Options I have thought about are

  • Auto Mappers - we have an issue with team members/management completely resisting with introducing new tool at this point because of criticality of timeline and in experienced developers. I was thinking of MapStruct
  • C# dynamic/anonymous classes - not possible in java/Jackson like in C# (or may be there is a way?)
  • Return the entity directly - not possible / summary APIs (so Jackson annotations not enough) are a must because the Consumer team doesn't have the capacity and I feel DTOs do seem to remove/add properties usefully instead of clutter of data. Adding another layer between (like in netflix) is not going fly at this time.
  • Custom Serialization code - Have not invested into this much but I think they might be less readable/maintainable than DTOs

So I have exhausted all options and I think for now DTO classes are just fine at this moment? or From you experience any way you have solved too may DTO problem?

  • Why is that a problem? – Laiv Apr 16 '19 at 12:30
  • @Laiv thats what I am asking if its a problem or if its fine? We dont write unit tests for DTOs. So there is no high cost. But I dont have any experience with large projects in Java with so many DTOs. I have in .Net , so just asking since in some stackoverflow exchanges they mention too many DTOs are bad and in some they say its perfectly ok. – Dexters Apr 16 '19 at 14:00
  • How many DTO's are we talking about here? Is it one per table in your database, or more than that? – Robert Harvey Apr 16 '19 at 14:50
  • It's bad if It takes you too long to maintain. DTOs are cheap to add and cheap to modify. It uses to be the opposite. Reusing DTOs makes things harder and cumbersome. In the line with Robert's question? How many DTOs are we talking about and what causes you to add new ones? Maybe the problem is the API. Maybe It's not robust enough... – Laiv Apr 16 '19 at 15:48
  • @RobertHarvey and Laiv its actually multiple classes (2-3 or even 4) per api end point. Its because we are doing summarization at multiple levels. For other straighforward apis requesting business objects its just 1 output model per api end point (to get that standard structure which we can reuse). My opinion is that consumers should summarize (eg. counts, category based counts, etc) but its beyond my pay grade to enforce. – Dexters Apr 16 '19 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.