C
C#3y ago
bookuha

DTOs and the data in them

1) Should I have two different DTO's (requests) for POST and PUT? 2) Does the DTO on the picture look fine for you? Can I make it any better? or you cant say because DTOs are entirely dependant on what your frontend needs
12 Replies
M B V R K
M B V R K3y ago
From my experience I think it depends on what front-end needs Sometimes you will deal with the same data iin the POST and PUT , in many times I used the same model (means the same model used in POST it is the same used in PUT) but from my experience and what I learnt by practice is better to separate them every request should hae a separated model I hope if there is any other experienced memeber here to share with us his expeiene
Esa
Esa3y ago
Looks fine to me. I'd question why Gender is a bool, but beyond that I don't see an issue. Generally DTOs are just a contract between you and frontend. If you can re-use that contract in different contexts (endpoints) with frontend that's fine.
Mayor McCheese
Code reuse is good; like @Fyren said make a new model when it makes sense; having disparate models for each request feels like you’re afraid they might change later so you want to build the complexity in first, just in case you need it. I’m against that.
bookuha
bookuhaOP3y ago
got it! so i just dont really have to care about if my dtos make sense etc etc. frontend people just may request “i want just name and surname from this entity, and i want it concat’ed by server” and i would be fine with this kind of need my initial thought on this process was to always send back the most full response, even if there are 8 nulls in 10 fields json but seems like it can be done any way and it is not really my work to guess whats going on there
Mayor McCheese
You got it But think about info leakage too So imagine PersonDto which you nest in full responses, and someone adds GovernmentId, this could now potentially get sent in all nested scenarios without any intent to send it
bookuha
bookuhaOP3y ago
hmm, so id have to make PersonWithGovernmentDTO for this scenario? that would live in the context related to governments and persons
Yawnder
Yawnder3y ago
What's important is that you generally do what PUT and POST are supposed to do. (Or whichever verb in general.) Don't go around using a GET to delete data for example.
Mayor McCheese
It depends on some regulatory requirements probably but something like that
Tvde1
Tvde13y ago
What I've seen done for a bunch of CRUD endpoints is:
class EmployeeForModification
{
public double Salary { get; set; }
public string FavouriteWord { get; set; }
}

class EmployeeForCreation : EmployeeForModification
{
public string Name { get; set; }
}

class EmployeeResult : EmployeeForCreation
{
public int Id { get; set; }
}
class EmployeeForModification
{
public double Salary { get; set; }
public string FavouriteWord { get; set; }
}

class EmployeeForCreation : EmployeeForModification
{
public string Name { get; set; }
}

class EmployeeResult : EmployeeForCreation
{
public int Id { get; set; }
}
This way, everything that can be PUT is in the ForModification. Everything that can be POST'ed is in the ForCreation and everything together is in the Result this way you separate the fields that can be updated, or can only be set during creation, and the Id which you cannot update
Mayor McCheese
For updates I often need to use something like json patch, for a stronger audit history Lots of situations fit different needs
bookuha
bookuhaOP3y ago
nice! looks very cool
Mayor McCheese
Really do the minimum

Did you find this page helpful?