C#•3y ago

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•3y 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•3y 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•3y ago

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.

bookuhaOP•3y 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•3y ago

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

bookuhaOP•3y ago

hmm, so id have to make PersonWithGovernmentDTO for this scenario? that would live in the context related to governments and persons

Yawnder•3y 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•3y ago

It depends on some regulatory requirements probably but something like that

Tvde1•3y 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•3y ago

For updates I often need to use something like json patch, for a stronger audit history Lots of situations fit different needs

bookuhaOP•3y ago

nice! looks very cool

Mayor McCheese•3y ago

Really do the minimum

Gaming

Programming

DTOs and the data in them