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.
@juliocasal Жыл бұрын
Good call, agree!
@josecarlosmacoratti Жыл бұрын
Great !!! Using extension methods is the best way in a simple scenario .
@juliocasal Жыл бұрын
Yes it is!
@baranacikgoz Жыл бұрын
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
@juliocasal Жыл бұрын
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.
@pazzuto11 ай бұрын
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.
@livan3li089 ай бұрын
can you share what the extension you use when creating c# files by right clicking in vs code explorer menu?
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?
@juliocasal Жыл бұрын
Yes, absolutely
@goqsane Жыл бұрын
@@juliocasalthis is what we do too, extension methods .ToDto.
@juliocasal Жыл бұрын
@@goqsaneGreat!
@podeig Жыл бұрын
Super tutorial, Easy explained and precisely what I needed. Thank you!
@juliocasal Жыл бұрын
Great to hear!
@faridulhuk1248 Жыл бұрын
Is it possible to create Mapper for Mapping dto to Entity , reverse way
@juliocasal Жыл бұрын
Everything is possible!
@torrvic115610 ай бұрын
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.
@juliocasal10 ай бұрын
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.
@electronicheartbreak.5 ай бұрын
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?
@juliocasal5 ай бұрын
The DTO is the input. What would you validate?
@pazzuto11 ай бұрын
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.
@juliocasal11 ай бұрын
Great tip!
@redouane5626 Жыл бұрын
I have habit that I do not use DTOs for API return types, instead I call them Models, is this right or wrong?
@juliocasal Жыл бұрын
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.
@perelium-x4 ай бұрын
Tysm
@rikkoo4 ай бұрын
beautiful
@perelium-x4 ай бұрын
Ikrrrr
@benchmarks101610 ай бұрын
upto 2:20
@somaticHuman Жыл бұрын
I prefer to use user-defined explicit conversion operators inside DTOs, instead of extension methods...
@santhnu Жыл бұрын
Would love to know how you do that? Would it offer any advantages/ease of use over extension methods? Thanks.
@agat366 Жыл бұрын
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.
@juliocasal Жыл бұрын
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!
@goqsane Жыл бұрын
Horrible advice. Don't follow.
@coding-esmaster3259 Жыл бұрын
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.
@sagarmajumdar92 Жыл бұрын
@@goqsane which one is the bad advice? What is shown in this video or using automapper
@goqsane Жыл бұрын
@@sagarmajumdar92using automapper. It'll bite you in the long run.