How To Use DTOs In .NET REST APIs
Вставка
- Опубліковано 12 чер 2023
- 💻Watch the full tutorial: • ASP.NET Core Tutorial ...
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.
🔥Become a Senior C# Backend Engineer: juliocasal.com/courses
🗺️Get My Free .NET Backend Developer Roadmap: juliocasal.com/roadmap
Join me on Patreon: / juliocasal
Follow me on LinkedIn: / juliocasal
Follow me on X: x.com/julioc
#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.
Good call, agree!
Great !!! Using extension methods is the best way in a simple scenario .
Yes it is!
can you share what the extension you use when creating c# files by right clicking in vs code explorer menu?
Here: marketplace.visualstudio.com/items?itemName=kreativ-software.csharpextensions
@@juliocasal thank you very much.
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?
Yes, absolutely
@@juliocasalthis is what we do too, extension methods .ToDto.
@@goqsaneGreat!
Is it possible to create Mapper for Mapping dto to Entity , reverse way
Everything is possible!
Super tutorial, Easy explained and precisely what I needed. Thank you!
Great to hear!
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
The data components should have no need to deal with DTOs, which goes for EF code too. Entity to DTO conversion is a higher level concern.
I do this for my "queries" (CQRS). I only bring back what I need from the database straight into a DTO whether it's EF, Dapper, or ADO. In some cases, I create a SQL View and I do a straight map. To alleviate the issue as Julio described for the endpoint changing, there's yet another object usually called a contract (following REPR): Entity Object -> DTO -> Response/Contract. But, I do use a DTO as the contract in lots of cases.
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.
Yes, it would be best to keep the data annotations out of the entities. I don't see a problem with using them in DTOs.
For a small set of DTOs, a single file is OK. If you have many, a file per DTO would be better.
I have habit that I do not use DTOs for API return types, instead I call them Models, is this right or wrong?
The name is not as important as the fact that you should not return the class that directly represents your DB schema. Sometimes I also call this Request or Response.
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?
The DTO is the input. What would you validate?
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.
Great tip!
upto 2:20
I prefer to use user-defined explicit conversion operators inside DTOs, instead of extension methods...
Would love to know how you do that? Would it offer any advantages/ease of use over extension methods? Thanks.
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.
Thanks, not a big fan of AutoMapper, and extension methods have been working great for me. But it's all a matter of personal taste!
Horrible advice. Don't follow.
Uff I would recommend not to use auto-mapping for projects does are not prototypes, auto-mapping becomes a headache when you change your models and you only get the errors in run-time instead of compilation and that's it is only example of another issues that you inherits by using AutoMapper.
@@goqsane which one is the bad advice? What is shown in this video or using automapper
@@sagarmajumdar92using automapper. It'll bite you in the long run.