Это видео недоступно.
Сожалеем об этом.
A Better Way to Transfer Your Objects in .NET 🚀
HTML-код
- Опубликовано: 11 мар 2024
- 🚀 Join the .NET Web Academy: learn.dotnetwebacademy.com
💖 Support me on Patreon for exclusive source code access: / _patrickgod
🚀 Get the .NET 8 Web Dev Jump-Start Course for FREE: dotnet8.patrickgod.com
🐦 Let's get social on Twitter/X: / _patrickgod
🔗 Let's connect on LinkedIn: / patrickgod
#DotNet #AspNetCore #WebAPI
Although I don't like relying on third-party mappers, I absolutely agree with the use of DTO's. While EF is a database abstraction, it's a tightly-coupled one, so creating DTO abstractions on top of it opens up so many more great options that make them far more flexible, secure and just generally usable, especially in the UI and with API integrations.
Utilizing EFCore is an option in some cases, but I just want to mention that Mapster has some other capabilities too, such as code-generation, which creates a highly optimized mapping that is both, fast and very efficient in terms of memory-allocation and so on. I guess it really depends on your use-case (as always :D...)
Nice video, Patrick :)
I've been using Mapster for the last couple of months instead of AutoMapper, whoever, still do prefer using a manual approach due to performance concerns and even more due to debugging
Thanks for this. This video appeared on my feed today, and it was literally 6 hours ago I was searching for the best way to do this! Nice one, thanks again.
Patrick, thanks so much for the video.
Mapster is a great tool, however, I wouldn't say I like the configuration method at Program, to me, it looks so out of context. Especially in a bigger application with a great number of DTOs. Do you have any recommendations to keep the configurations "closer" to the types declaration?
Hi Patrick,
thanks for the clear and understandable Video! Would you consider to go a bit deeper into mapster?
I've been trying to use it before in my project but I gave up when mapping configuration got too complex and I didn't really understand it anymore. For example I have a mapping of a deeply nested Object-Structure (basically it serializes into an xml) and in my manual mapping I end up with something like this: XmlFile.Response.Document.Positions[0].Price.Freight = data.PriceItem.Freight;... At this point I ended up with loads of AdapterConfigs and it still wouldn't work, until I finally gave up and made a manual mapping again. I'd highly appreciate if you'd dive a bit deeper into the Mapster-Topic.
You've helped me out so many times with your videos, so even if the deep dive is no option: Thanks so much for your work "und Grüße aus dem Süd-Westen" :D
i want kindly ask the records instead of dto classes. I have seen soo many to use record advices but never seen using records instead of dto classes
Ive been thinking about this a lot lately! Mapster looks cool will try it out. Another great video thanks
Nice vid Patrick !!!!
Thank you Patrick
Thanks for your video and alternative way of mapping entities. At the first glance it looks nice and easier comparing to the automaper, but there is always something to be sacrificed😅
Interesting. I always have the ID in the base entity.
Yes, you're absolutely right in doing so. I totally missed that when recording the video.
Hi, nice video!
I have an api and I don't return entities directly but dtos that are practically the same as entities, shouldn't be created the specific dto or viewmodel in the service class of application layer? Alternatively the other option should be to return IQueryable in case of ef core, but this doesn't protect your database. I would implement in the service layer all methods that can return different dtos or viewmodels for UI. I am wrong?
I expect the name mismatch scenario to be covered but kind of expected mapster to provide attributes (Decorators?) for the Dto or something which would configure custom mappings where auomatic ones are not possible. Imo would be more neat. Never heard of mapster btw, just saying I assumed it to be like that..
IMHO Mapperly is the way to go.
I Agree with you. It seems to me mapster is also using reflection which means runtime mapping. Mapperly doesn't do that. It generates mapping code during build time, which is even more way, way faster than Mapperly because that way, reflection is not needed anymore.
@@Cornelis1983Yes Mapperly uses code generators, so everything's ready before runtime.
Mapperlly for best performance because it not use reflection
I don't really see the difference between this an AutoMapper.
Thank you for the video. I'd like the ability to return a DTO that is somewhat dynamic. Maybe you just specify the properties that will be returned or not returned. For example, in some cases I may want to return the characters without the inventory and in other cases I do. I know it's not a big deal to create two different DTOs for the situation, but it would be nice to be able to say return characters and and just specify something like without property inventory or something like that.
I prefer transform entities into DTOs manually. The power is mine, the properties name of DTO can be different of the entity property and this make sense and lot of scenarios. AND keep simple!
Just curious - if you're not returning IDs in your API calls, does that mean you also will not create an API route that looks like this: /api/character/detail/{id} - and if not, how would you define a character detail call instead?
He was just using the Id field to demo the functionality. 99% of the time your payload would include some kind of ID.
@@leftjabrighthook If that is the reason, than it sounds to me like it is a bad demo. I got me confused as well. The fact he left out just the dates field would already be a good demonstration.
I don't like too much extensions. It violates Single Responsability. Compared to this, I like how AutoMapper does it. An additional Profiler class is fine for me!
There are tons of these auto mappers. Just makes the code more reliant on third-party libraries. Better off copying these things into ChatGPT and let it generate the mapping code for you.
nice !
that does look nice!!
Wow its great!
Why no .Map(), why .Adapt() bruh