How To Use DTOs In .NET REST APIs

preview_player
Показать описание

A Data Transfer Object, or DTO, represents a shared agreement between a client and a server about how data will be transferred and used.

In this video I explain why you should use DTOs and then I go over a practical implementation in a simple C# based .NET REST API.

#csharp #dotnet #aspnetcore
Рекомендации по теме
Комментарии
Автор

By C# conventions you should use "toDTO" instead of "asDTO" since the method returns a new object. The "as" word is used for when you want to imply that something is being casted AS something.

failscript
Автор

Great !!! Using extension methods is the best way in a simple scenario .

josecarlosmacoratti
Автор

Great tutorial! Is it possible to utilize extension methods for complex DTO mapping without any external libraries? Do you consistently employ extension methods for DTOs without relying on any other mapping libraries?

saddamhossaindotnet
Автор

Super tutorial, Easy explained and precisely what I needed. Thank you!

podeig
Автор

I prefer project to dto feature of entity framework [ like _dbContext.MyUsers.Select(x => new MyDto(x.Name, x.Surname)) ], or you may achieve the same thing with dapper. No need for a dto conversion again in this way, unless you're dealing with in-memory collections

baranacikgoz
Автор

can you share what the extension you use when creating c# files by right clicking in vs code explorer menu?

livanli
Автор

Thank you so much! That was exactly what I searched for but however I apologise sir but as far as I know it goes against the Clean Code principles to use decorations on your Entities. They should be as clear as possible because they correspond to the tables of your database. And is it Ok to use decorations with your DTOs also? Or do I don't understand something?
And also why your records are not in different files but in one Julio? It looks not Ok in my opinion.

torrvic
Автор

Is it possible to create Mapper for Mapping dto to Entity, reverse way

faridulhuk
Автор

I'm surprise that for Post/Put/Delete, you did not use extensions. You could extend DTO just like entity with a method like ToEntity. That way, your mapping is all in the extensions class, and your endpoint doesn't need to know about this conversion.

pazzuto
Автор

I have habit that I do not use DTOs for API return types, instead I call them Models, is this right or wrong?

redouane
Автор

I have some questions:

1. Why do you add validation on the DTO, since input CAN and "should" be invalid? You also now have duplication in validation rules.
2. Since you added validation on the DTO, you do not check the validity of the input by if Modelstate.IsValid. Why?

electronicheartbreak.
Автор

I prefer to use user-defined explicit conversion operators inside DTOs, instead of extension methods...

somaticHuman
Автор

From my long experience, it’s quite inconvenient and time-consuming to define all the transformations. Imagine if you have several dozens of DTOs, also, it’s inconvenient as you have to make all the transformations changes manually after refactoring. I believe, more standard approach is auto-mapping. The only thing I would consider would be embedding AutoMapper into the AsDto extension methods.

agat