Do You Really Need a Data Transfer Object?

Let's discuss the benefits and drawbacks of having a separate DTO class rather than using a domain object as a DTO.

🕗 Timestamps:
0:00 - Context
1:16 - Benefits
3:57 - Drawbacks
5:05 - Use Cases FOR NOT Using a Separate DTO Class
6:52 - Use Cases FOR Using a Separate DTO Class
8:02 - Main Takeaways + My Opinion

➖➖➖➖➖➖➖➖➖➖

© Credits

[zwatotem]

I like that this channel actually doesn't just blindly teach whatever is widely considered "the best practices" as a given truth. Instead it asks these questions that I also frequently have, challenging the authorities with well thought out arguments.

[prakticamode]

You are a gem on youtube. Am developing an application that will have to have its datasource migrated (no concrete details yet) so i am now expanding the project with DTOs just to be prepared. It also helps clean up the original object model nicely. Love your videos.

[jrosimo]

Im going into my first year as a Software Engineer and im now only learning about DTO, finally i get to understand it. Thanks Sean!

[michaelkhalsa]

Another benefit is that you can close the db connection more quickly with a dto. When populating tens of thousands of dto objects this can be significant. In addition simple methods can be added within your database layer to quickly populate a dto by index, rather than names from your sql results, which is dramatically faster for large queries. The same to dto methods which take a data reader can be reused for calls returning a single row or thousands. Its a touch more work than using an orm to handle all the mapping, but benefits are tangible.
.

[erikjlee]

Great video Sean. If you adhere to Model Driven Engineering/Architecture concepts, your domain model is the DTO. In the utility industry, IEC CIM is a domain model that doesn't define behavior, only structure. However, IEC61850 defines both behavior and structure for it's more specific use cases. Like you said, "it depends." But personally I would not want to maintain two large models. Simplicity is key IMO.

[dono]

At the start of new projects I often try to get away without needing to define DTOs. However, except for the most simple projects, as the complexity grows I eventually need to refactor and define DTOs. In hindsight I often regret not defining DTOs straight from the beginning.

[edpoitras]

The content in this video is excellent and gives good examples as to why you should or should not use the dtos thanks a lot

[DanimoDev]

Great video Sean, and you are right, it depends, I don't think there is a definitive answer. Personally, I lean towards DTO's, they can add complexity for sure and it's another thing to maintain, but they act as a contract for incoming/outgoing data. With DTO's, the I/O data contract doesn't have to be the same as the apps domain models, and having that separation and the flexibility it gives can save some pain later.

I suppose it really does depend on context and preference though, sometimes it is overkill for a really small app and/or where you are almost certain the data will always maintain the same shape in/out the app. However, in other cases you might be using a 3rd party or an existing service and will need to reshape/map data both ways.

[vincentotieno]

Mmh... finally I have some clarity on the differences between domain objects and DTOs, and when I should use them. Thanks for the clarification.

[TheTigerus]

Typical SQL database has names of columns only with lowercase letters and words are separated with underscore. When I'm using Dapper, i need my property to have the same name as column name, though it can be uppercase. There is no way I'll have variables named like: Some_Variable in my C#, so I'm using DTOs to fix the problem

[TornTech]

Wait, what? Iv always used “Models” for my binding of data against SQL through stuff like EF… a DTO for me, is something I expose out of my repository or something so it doesn’t tarnish the model.

Like I might get a PERSON (Model) from EF which contains all this stuff About the person but would expose a BasicDetailsDto which may only care sboit the name and age of the person.. that way I’m not exposing too much and I’m not coupled to my Data model so they can grow separately.

It sounds like from the video (Iv not finished it yet TBF) that you see models and DTO’s the other way around…

What do/would you use on your DbSet<> in an EF DbContext for example?

[leduchoan]

DTOs are good, however they somehow quite hard to manage cause of reflection.

[SirBenJamin_]

Hang on - isn't this the guy from American Pie?

[nahomb]

How about using composition instead of DTO?