C#C
C#•3y ago
D.Mentia

❔ DTOs Pros and Cons

Backstory: At work, we use models that contain DB entities, and we expect them to be partial; they should be Selected from the DB with only the minimal required data. I'm trying to convince them to use real DTOs instead, and what I'm hoping to do here is list my arguments, and see if anyone has any arguments against them that I should consider

To be clear, instead of 
class PatchMyEntityModel 
{
  MyEntity Entity {get; set;}
}

I want
class PatchMyEntityModel
{
  required Guid EntityGlobalId {get; init;}
  string? Name {get; init;}
  DateTime? Date {get; init;}
  // ... etc
}

(Especially because the endpoint only supports updating a few specific properties, not all of them; entities might still be used in DTOs when they are actually needed, but ideally only internally)

If I'm confused about what a 'DTO' is, let me know, though. I just want them to have explicit properties so I don't have to hunt through a chain of 12 methods that will be called with my model, to see what they all expect me to pass
And yeah I'd rather use records, but there are some reasons we can't do that just yet

DTO Pros:
  1. Explicit properties that clearly show what data is required for this endpoint
  2. Explicit return values - consumers don't have to wonder if a null might just mean we didn't Select that column
  3. The capabilities of the endpoint are clearer
  4. The caller can't include more data than necessary; reduces network overhead
  5. Compile time errors instead of runtime errors, if giving the wrong arguments to an endpoint or trying to use return values that are not supplied from it
  6. Runtime errors are a HUGE problem, the main thing I'm trying to solve here, and they are common when using entities because callers may not include the correct data in the entity, or may expect data in the returned entity that isn't actually populated
  7. Decouples MyEntity from the API, MyEntity can be freely modified without affecting clients or endpoints using DTOs (as long as it can still fit existing DTOs)
  8. Allows specific intellisense-capable documentation comments on each property
DTO Cons:
  1. Maintenance; if a DB entity is changed, in some cases, all DTOs using the changed column must be updated alongside the logic. This may (at most) double the number of places in the code you need to modify for an entity change
    (But even with entities, the logic still has to be updated, and all consumers must update their logic and your package - even if the change was superficial like a rename, which DTOs could allow without making the clients aware of it. Plus, updating the DTO is no different from updating a method signature, or updating an interface; it's not hard, the compiler tells you where and what to do, and it's worth it to have a contract)
And... that's it, I think. Thoughts?

Clearly I seem to be underestimating the cost of maintenance, https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/august/pros-and-cons-of-data-transfer-objects seems to imply that it's significant, but I just can't imagine a scenario where maintenance for DTOs is significantly more work than without.
Any time a DTO would have to be modified, the logic using an entity would also have to be modified. It's not at all hard, while you're there, to F12 to the DTO and update that too - that may even be the first thing you do, it's no different from updating a method signature if you're changing what that method takes. DTOs also allow some of those changes to the entity without changing the DTOs or forcing clients to update, whereas passing around entities does not allow that in any case
Pros and Cons of Data Transfer Objects
Was this page helpful?