C
C#3y ago
bookuha

DTOs inside of DTOs

Is it normal to have class GuyDTO{ string Name {get;set} int Age {get;set;} BikeDTO Bike {get;set;} } Like, I should have BikeDTO always, not the Bike entity itself, right?
10 Replies
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
bookuha
bookuhaOP3y ago
so like to create my specific BikeDTO inside this GuyDTO class? wow, that sound cool i couldnt find any use for nested classes now i see
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Mayor McCheese
I keep my dtos as flat as possible. Sometimes you can’t avoid structure, and I accept that.
bookuha
bookuhaOP3y ago
does flat mean you have only primitive fields?
Mayor McCheese
Essentially It’s reductionist too; only send exactly what you need If you have a collection or something you don’t want to be obtuse and flattening
bookuha
bookuhaOP3y ago
hmm that makes sense. i just send everything, could i just replace BikeDTO with BikeId
Mayor McCheese
If you have a front end cache of bikes sure, could just be id and name of bike possibly
bookuha
bookuhaOP3y ago
like,”maybe youll need this” but if i had send bikeId, he would have been able to get the bike anyway by making another request because currently it is like Here - your person info.. and array of his bike info.. and here is info on bike creator…
Mayor McCheese
You might be sending bloat you never use Having a key value pair and extend bikes with requests as required Reduces some of that bloat Structure tends to increase object size Just don’t create an object with predefined slots @bookuha BikeId1, BikeName1… 2, 3, etc Like I said sometimes you can’t avoid structure; but keep it relevant

Did you find this page helpful?