Don't Use AutoMapper in C#! Do THIS Instead!
Вставка
- Опубліковано 3 тра 2024
- Don't use AutoMapper in C#. Seriously! It could affect your app's performance and looking at the way Automapper is usually configured, it doesn't really gain you any development speed. But what can we use instead? In this video I provide some alternatives to AutoMapper.
Join this channel to get source code access and other perks:
/ @codewrinkles
Contents:
1. Intro: 00:00
2. An AutoMapper disaster: 00:50
3. Alternative 1: Direct class mappings: 03:34
4. Setting up benchmarks: 06:05
5. AutoMapper, bad performance: 07:20
6. Alternative 2: Implicit operators: 08:33
7. New benchmarks: 09:58
8. Alternative 2: explicit operators: 11:48
9. Conclusions: 14:04
My setup:
Camera - Canon EOS M50 Mark II: amzn.to/3SJxS4d
Lav mic - Rode Lavalier GO Professional: amzn.to/3mmZS1B
Condenser mic - Shure SM7B: amzn.to/3JaqjQN
Audio console - Rodecaster PRO II: amzn.to/3KTVMIg
Laptop - Dell Latitude: amzn.to/3KV4SEW
Monitors - Benq 27 inch: amzn.to/3JbM6aU
Lights - 2x Godox SL-60W: amzn.to/3KV3qCj - Наука та технологія
Another alternative that could be in the same perf class and allow having no relation between the objects within the classes directly, could be to use extension methods. It still has the advantage of being static, can be hosted in a separate assembly that is only referenced to where mappings are required so the general consumers are not presented this option.
I second the oppinion of the commenter who requested a memorydiagnoser run as well with the benchmarks. There are pretty surprising findings on that front with AutoMapper, the other options are pretty clear allocation wise, since the code is in front of our eyes. Considering the abundance of slapping together AutoMapper and DI, it could possibly lead to some intresting results depending on lifetime
No one can deny the most redeeming quality of the library, not even the author itself. It is a godsend for the cases where there is no manual mapping in terms of maintainability. Saves a lot of time that would be spent maintaining code. One could argue that it prevents having bugs by missing some mappings. In the end it still is magic code that is not checked in source control and cannot be analyzed on compile time by code analysis tools.
At the same time source generation and custom analyzers are becoming more widespread so there could be alternatives for making life easier without reflection at least partially.
I feel Automapper is initially used by people because of your third paragraph, No manual mappings = godsend. This is the reason I first used Automapper with 100's of 1:1 mappings I would have been there for hours typing out the same thing.
As Codewrinkles has pointed out, people use it once and then the critical thinking goes out the window and they start using it for manual mappings where it would be better to include that logic in the appropriate spot (where ever that may be).
The main point is really to think about everything you're doing and not just turn on autopilot because "I used it before and it was great".
Functionally and practically, planning projects from the beginning, it make sense to map fields and properties using the same naming conventions, thereby removing the need for mapping. Personally, I prefer using DTOs to calculate derived properties from the business layer. If it's a security concern to use the same naming conventions used in the database, that's a different conversation. Debugging is much simpler for newer coders working in legacy code when they don't have to trace back the mappings of irregular conventions. I've used Automapper, but never for large record sets.
When Name == Product or Name == Nomenclature or Name == Manufacturer + ProductName, it's not good scenarios for ease and timely debugging. I've seen some crazy spaghetti code because of the changes required by new management or requirements due to changing standards and regulations when it comes to DTOs.
It is an alternative, but it comes with its own problems. To name a few: if you add extra properties to one of the models it can be missed in the DTO and vice-versa. Automapper is throwing errors on unit test. Second: you just shift business logic to DTO that is not part of the domain logic. If you put the transformation in the business model you create a dependency to DTO that is usually part of a infrastructure layer. So I personally think it's worse and does not tackle the real issue of separation of concerns. The speed issue is something you can ignore in most real world application. That is because the real slowdown resides in the Infrastructure latency.
That's what I have specified in the video at least 3 times, that you wouldn't want to put mapping logic in the domain model. That logic should be placed in the DTO, as this is what a DTO is at its essence.
@@Codewrinkles And than the DTO contains business logic, that should not be there in the first place.
@@mercere26 Well, parting from my example. that would be a method on the domain model that calculates a price. But other then that what would be business logic? Mapping logic (logic that doesn't contain domain behavior) is the quintessence of a DTO.
@@Codewrinkles So the issue with the automapper is just related to performance than? My bad I though it was about logic that doesn't belong there. Or at lest this is my concern when using it. Because if I'm reading right what you say you just shift the calculation to domain and than you can just call it in the automapper the same way you do it in the DTO, so it's the same.
@@mercere26 From my point of view, there is a big issue of logic that doesn't belong there. However, that's not AutoMapper's fault. One of the things I find annoying is that AutoMapper has become kind of a default go to in .NET projects. And the problem with defaults in general is that they eliminate critical thinking. My main aim with this video was to actually draw attention on these facts and try to re-enable critical thinking when it comes to AutoMapper.
AutoMapper has also a lot of great other features, like projections that might be useful at some points. However, when I look into different projects and during interviews I'm always getting depressed on how AutoMapper is used.
Therefore, my conclusion for a lot of cases is that it's better to not use it at all, than use it so wrong.
I recently had some interviews; you will not believe how many tech leads asked me about automapper. I have been using direct assignment for all my projects. I will give "implicit" and "explicit" a try! Thank you, very informative video!
During interviews I also ask candidates about some libraries they use. It's important to gain an understanding of what overall tools that candidate is used to. However, I am 99% sure that no sane technical interviewer will reject a candidate because he/she doesn't use or know in depth how AutoMapper works.
My main problem with automapper is that it will not catch name changes so unless you have unit tests that test the casting you can end up with broken code but if you add all the unit tests you end up writing more code than if you wrote your own mapping.
That you also get better performance is just an extra bonus.
I also avoid implicit casting and opt for either a factory class, From... methods or similar since it creates easier discovery for new developers. implicit is not easy to see.
Extension methods work BUT if you forget to include it you will not find the methods for casting so with extension methods you will need a namespace you always will include.
More verbose but easier to read code will always be better than "clever" code ;)
Good video with some great information. Thank you.
I would like to point out a few things in reference to your examples.
1) Business logic never belongs in the mapping for AutoMapper. If that occurs, it is bad coding practice and not the fault of using AutoMapper.
2) Business logic never belongs in a DTO. Again, just bad programming practice.
3) The most valid point, I believe, you are making here is the performance loss with using Automapper. And that is a valid point. As developers, we are constantly trying to balance code for security, performance, and maintainability/readability. When used correctly Automapper can help a lot with maintainability/readability, but at a cost of some performance loss. I find that the gain in maintainability/readability in the code is of higher value than the performance gain of not using it, most of the time.
There are also other cases like ours. Our current generations data structure and data layer is to be adapted in our new generation of products. We map old DTOs into new ones. The old naming is terrible so new DTOs are getting a makeover. In that case, most properties have to be mapped manually, so using AutoMapper is close to not being worth it.
Thanks for the video! I agree with you, but unfortunately, like with every other mess in software, it all begins with good intentions
The idea to use AutoMapper usually starts with "everything will be clean and it'll do work for us" that's how everyone falls into that trap. Then begins "Oh, we need to map this explicitly and map that explicitly and let's also add this logic here too".
One advantage, if you can call it that, of AutoMapper is that it's used so widely in the industry that when you need to find mappings in an unfamiliar project, you by default start looking for AutoMapper and you'll most likely find it. With custom mappings, they could be spread in classes like you demonstrated and their purpose may not be clear immediately. You may create a "Mappings" folder and move them in there but then again, every mapping will need to be done manually, even the "auto" one, at which point somebody on the team wanting to score some smart points will suggest AutoMapper to save time, and we're back to square one 😂
That's a very nice comment and appreciate your points. I of course also agree with what you said there. To extrapolate a bit, I'd say that AutoMapper has become a de facto default on all applications. The problem with defaults is that they eliminate critical thinking. And then, attrocities happen. The main purpose of this video is to bring some of the critical thinking back.
It feels to me that your argument is “because some people use automapper poorly, nobody should use it”.
I disagree that it shouldn’t be used because poor developers will misuse it. Like any tool, it can be used well or poorly. It’s the job of the team to keep the code clean, performant, and maintainable.
Having worked in many large legacy apps with mountains of technical debt, I feel that it is far far far more important to reduce complexity, code clutter, and and multiple ways of doing the same thing. It makes it easier to read, easier to understand, and easier to maintain.
I agree that business logic should not ever be in a mapping, unless the mapping is the logic. So it’s much easier to forbid mapping business logic than it is to change technology.
Performance, of course may be an issue, but I take the Knuth approach of choosing good algorithms and tools for the job, but not worrying about performance tweaking until it becomes a verifiable problem. If you use good strategies in design, performance issues are usually a small percentage of the problems you face.
To that end, I use best practice strategies when writing code, including separation of concerns, even when using tools like AM. In fact, using AM has the benefit of neither the domain or the DTO having to know about each other. And if you keep business logic out of it, all concerns are separated. Certainly there are other methods to achieve this, such as extension methods, But this means each developer has to make individual decisions that can lead to inconsistencies.
Plus, more mapping code = more work, more testing, and more chances of mistakes. More to maintain too.
Code generators are often touted as solutions to some of those problems, but they create explosions of code, bloating a code base by massive amounts. This code can easily become out of date, and create more bugs. One advantage to a an automated mapper is the ability to detect missed mappings. Although you also have the possibility of incorrectly implied ones as well. And of course this tends to be a runtime detection rather than compile-time, but one that would be found in unit testing.
Yes, if you need the performance, by all means, hand tweak things. But don’t stop using hammers because some people don’t know how to hit nails correctly.
Choose the fastest performance way is not always the most important thing. It depends on others factors like clean and easy maintenable code (something ignored by rookies or early C programers). If we think so, probably we will not use c# and we will be still coding directly in assembly machine code. This is enginering and every way we choose has pros and cons. We only have to know and measure them when taking a decision.
I understand your points and I'm still a little bit mixed between using and not using AutoMapper:
(1) I guess the obvious thing with manual mapping is breaking the Open-closed principle of SOLID
(2) I like AutoMapper for a reason even Jimmy mentions: It enforces convention. I worked on a project where mapping
was done 3 different ways (can be solved, but AutoMapper already gives you defined conventions that other developers might already be familiar with). This also makes jumping into a new project much easier. You do not have to learn anything new, if you already know AutoMapper and the new project uses AutoMapper.
(3) I agree with the business logic. Do you think, that separating AutoMapper's value resolvers to domain layer would be somehow reasonable
solution?
(4) Implicit operator hides too much for me. The assignment might not be super obvious at the first sight.
But definitely awesome to know what the tools you use actually do.
Very nice comment. Thank you.
1. How does manual making brake OCP? The only reason to change the mapping configuration is, well, when it needs to change. You don't modify anything to add new behavior, introduce switch cases or something like that.
2. I agree with the conventions part. However, in a lot of practical, real-app scenarios, sticking to the conventions actually pollutes property and class names, especially if you want flattening to work. It practically means that when I'm constructing my DTO, I will have to name class properties in a way that I know it will work with the AutoMapper conventions. From a system design point of view, I think this is not optimal.
3. I think it might be reasonable, though there might be some edge cases. For instance, what if that custom logic actually only applies when the mapping is done and it's not needed anywhere else? Tbh, I don't really have a strong opinion on that. Overall, I try to avoid value resolvers as much as I can
4. I fully agree with that!
This being said, I know the title of the video is strong. From where I standing I see that AutoMapper has become a default tool in .NET projects. And the problem with default tools is that they eliminate critical thinking. We just use AutoMapper because it's kind of a default. That's what we see. With this video, I just wanted to bring some critical thinking back.
@Codewrinkles
(1) Hmm, yeah, I probably took the OCP too far
Agree with other. Title is alright, it's UA-cam :D
@@denisthedev Thanks for the discussion
@@Codewrinkles Ok but I have to disagree with you on that. If implementing your methods (either direct mapping, implicit or explcit) you make direct dependency to ProductDto in Product class, which is IMO really bad design pattern, Classes, especially POCOs shouldn't really be aware of eachother. What if Product will have to be mapped to ProductRequest and then ProductResponse and then to CQRS patterned classes and so on, so on. We end up then in with a lot of "ToProdact..." methods. In this case I would rather create either extension method or static converter to handle this stuff.
@@Velociapcior I have responded in dozens of comments emphasizing that MAPPING LOGIC SHOULD NOT BE PLACED IN DOMAIN CLASSES. It should be part of the DTOs. That's the quintessence of DTOs.
I like the idea, which I also use mainly in tests for persona-to-model mapping. I remember you had a video about the ProjectTo method in MediatR. That feature is very nice when it comes to EF queries. This is the only thing, I miss with the "explicit" solution.
I totally agree with you on this one. However, the ProjectTo feature also comes with its own architectural and practical challenges. What is important for me and what I want to actually share in my videos is the idea that we as software engineers just need to be aware of the pros and cons of the tools we are using and make informed decision. I feel that AutoMapper is somwhat a de facto default in .NET projects, which eliminates critical thinking from the developers. With this video, I just want to bring that critical thinking back :).
@@Codewrinkles Yes, thanks for sharing your thoughts and videos 🙏
One advantage of automapper is being able to unit test 1:1 map, if I add new property to domain model and forget it in dto, AssertConfigurationIsValid in unit test will warn me. It's basic and automatic and it is quite hard to do same for any other map type like factory, constructor, implicit/explicit operator. I was hoping you would show some good semi automatic way using source generator
This is such an underrated comment, and it's really shocking that it has so little thumbs up...
But it does show how nanoseconds of "perf" is more important that maintanability to the majority of "devs"...
I have used Mapperly as a mapping source generator. It seems good. What you loose is projections and such if that is needed.
Thank god someone finally said it 😃 Stack overflow mapping questions almost always promote it even for very simple mappings.
I prefer to do an analogue to the Rust Into and From traits, so in C# either using interfaces, static member functions or extension methods. The reason I didn't like AutoMapper is that it isn't explicit when using reflection or when using a custom configuration is no different than writing my own code without the need of another external dependency.
"The reason I didn't like AutoMapper is that it isn't explicit when using reflection or when using a custom configuration is no different than writing my own code without the need of another external dependency."
Just look through the comment and see how many actually think that using AutoMapper they do things faster and with less code. Real project practice shows that it's really not the case. Devs spend a lot of time writing boilerplate AutMapper profile configurations.
so nice brow, thanks for teach this "explicit" and "implicit" operator.
Interesting topic! I believe that you must consider the memory analysis in this benchmarking, I am very curious about that. 😅
really Brilliant talk !!! If I want to Map from ProductDTO to Product ?
A little late at the party but, YES! I totally agree! It seems to me that this is an issue only with .NET frameworks. I never really understood the use of a mapper for cases like this. Your solution is the de facto one for all other frameworks. I read in the comments all sorts of things like breaking the OCP or having dependencies on each other. No, the OCP is not broken by using DTO's and secondly why someone would think that introducing a whole library into the game to do the coupling of POCO's and DTO's is any better? Your solution, simple, elegant and tells the story! Well done!
Great insights into implicity and explicit operators to replace AutoMapper. I thought though that you might have benchmarked using a public interface for the DTO which the domain model would implement. This would arguably be faster still (no copying) but might be a headache to code for.
Please note, however, that I have just provided some alternatives. People should evaluate and decide what they should give a try. The implicit operator, for instance, has its own downsides as well. Not in terms of performance. But it simply hides a lot of things away and feels like magic. The code is less understandable
We are working on a complex project, and my experience is, that the performance impact is the smallest problem. The bottleneck is our database access, because of complex business acl queries ...
What it comes a point where you need to resolve a particular property? I like automapper in some cases if I’m doing heavy projections but what I tend to do is have my own extension method that does my mapping for me like so :-
public static TDestination Map(TSource source)
You should add MemoryDiagnoser just for the sake of it. Thanks for the video!
Yes, would be good to see if Automapper uses any memory allocations in the background.
Nicely explained. Thank you Sir!
Glad it was helpful!
Extension Methods allow to put the ToProductDto() outside of Product but use it as if it were inside.
Agree with that. However I still stick to the idea that having methods or implic/explicit operators on the DTO is ok. That's what a DTO should do: transfer data. I don't see why we should use it in some external extension class. It's like moving domain model methods into some other class. Classes in OOP should have properties and behavior. Mapping behavior is a quintessential part of the DTO concept.
@@Codewrinkles What I don't like about implicit and especially explicit operators is the bad discoverability .. it's not very self-documenting... you need to know that functionality exists to be able to use it whereas a toWhateverDto() is easily discovered with code completion
@@DerClaudius I totally agree with this. And I wouldn't also abuse this However, this video was a good opportunity to bring these operators into discussion as a lot of .NET devs are not aware they exist. And there are situations where they might be useful.
Thank you so much for sharing you knowledge with us!
My pleasure!
I kinda have mixed take on this, first of all, implicit/explicit operators for dto conversion is not adviced, for fear of too much magic, a good number of people are not familiar with it. Secondly, automapper does really amazing projections when using entity framework, so the performance improvements from direct assignment would result in a more complicated codebase with custom projections
"a good number of people are not familiar with it." that's exactly why I have included them in this video.
Regarding projections, I have indeed created a separate video a few weeks back. Maybe you want to take a look and let me know your feedback.
Good video mate.
PLEASE when using BenchmarkDotNet decorate the banchmark class with the MemoryDiagnoser attribute. It will add a comparison of heap allocations to the results. GC preassure should be mentioned as a performance concern.
Thanks for the tip! I used the memory diagnoser in other videos when I did benchmarks. For some reason in this one I wanted to concentrate on execution speed. But I agree, what you say makes a lot of sense.
As some one else said here, you are missing the point of the automapper. Which is to save you from writing and maintaining a lot of unnecessary code that can be resolved automatically (hence the naming - Automapper).
And yes, it's using reflection, but it's also doing some caching and optimization with mapping expressions. As long as you don't have really intensive mapping in your application, the performance cost will be negligible - which is the case for 99.99% of the apps out there.
Looking at this comment I keep asking myself, have you watched the vide at all? Or, just the conclusion? Because strangely enough I even make the analogy between the library name and the fact that it's supposed to do things automatically.
thanks! I have stopped using automappers myself and currently use direct assignments in extension methods (is this okay?). I will explore the explicit/implict operator features as well.
I think extension methods are ok. TBH, I wouldn't probably use too much the implicit operator because it makes everything feel like magic. The explicit operator is better, because you explicitly need to specify the cast. I would put the explicit operator in the DTO.
@@Codewrinkles thank you sir! Much appreciated 🙏
Again a nice explanation. Thank you
it will be good if you can refactor your clean architecture course without automapper.
Which one do you refer to? CwkSocial?
@@Codewrinkles Yes. I have removed automapper in a project which i have just started and going with explicit operator.
Loved it. Thank you so much.
In automapper when I have different source objects I usually use a tuple. How would u do it with explicit operator?
The reverse mapping is missing in your demo.. wanted to check conformance in the reverse scenario.
Having static method in productDTO will cause json strong to be in mess? With unknown namespace or method name in it?
In one project I worked on we had 3 layers of different DTOs with the same fields all mapping to eachother with automapper, absolute nightmare to figure out which of the ProductDtos you were looking at 😅
That sounds also like a programming nightmare :)
"same fields all mapping to eachother" ?!? It looks like someone didn't know how to work with Automapper :P
What do you fink about mapping implementation using extensions methods?
As I mentioned in another comment, this is also a valid strategy in my opinion. Even though I think that having implic/explicit operator on a DTO, for instance, or mapping methods (FromMode, ToModel) is also not wrong as this is the essence of a DTO: transfer data. This implies mapping data.
i like this. this way, each class would still have no knowledge of the other class. that knowledge would be in the extension method.
Couldn't I use constructor to map a class to another instead of explicit/implicit operator?
For example:
ProductDto(Product product) {
Name = product.ProductName;
Description = product.ProductDescription;
Price = product.Price + product.Price * 100 / product.VatPercentage;
}
Would it make any difference?
It would work equally good. Extension methods also.
There is no reason why you could not use the implicit operator in the ProductDto, just replace explicit with implicit and then it is implicit the same as if it would be in the Product class, would work the same. (Of course it is right it would be ambiguous if you had two of basically the same operators, you just need the one in the Dto or the one of the non-Dto, I would say do it in the Dto.) At the end it doesn’t matter much if it is implicit or explicit, explicit just makes it safu castable, implicit makes casting obsolete, you can simply just assign to a var of the desired type to which exists a implicit operator (or use var keyword and do casting like with shown explicit operator).
And implicit / explicit operator are not faster than direct manual mapping (when doing the same), they should be considered equivalent in performance.
(With the point of the video I of course agree, better performance without reflective mapping, and less business logic in spooky places where it does not belong.)
(If mapping with mapping packages is really needed, I recommend using ones that use source generators behind the scenes which do it the same way as manual mapping, and or I can recommend Mapster, which has much better performance than AutoMapper.)
A downside of Mapster and the source generators approach is that (as far as I know) you can't do projections. AutoMapper projections are a cool thing. I even did a video on that one too.
What about using extensions methods to achieve the same thing? I basically have mapping extension methods inmy API layer, allowing me to keep my DTOs clean of any logic beyond their properties (oftentimes they're even records). Or do extension methods impose a performance penalty post-compilation?
I think I mentioned this in other comments as well, but yes, using extension methods to achieve this is perfectly fine. In fact it's even preferred when compared to using implicit or explicit operators, because those operators work more or less like magic, which is not good on the long term.
@@Codewrinkles Yeah, that's what I was thinking when I saw the operators. C++ also has implicit conversion and it is generally frowned upon since it can cause "magical" conversions to happen that can be tricky to track down. Especially if those conversions are defined in some other dll that is not maintained by yourself.
Either way, informative video!
I do my entity to DTOs in a similar manner to how you have done them in this video. I did not and still do not understand the benefit the value that AutoMapper has over just converting the entity with a method.
That's interesting. Are there any automatic ways to check if any mapping is missing? I can imagine myself mapping fields and letting 1 or 2 unmapped by mistake.
In AutoMapper, if that happen, I'm able to know that, and I can "Ignore" if the field is not needed.
You still need to unit test mappings, no matter if AutoMapper or not. And, yes, that's why unit tests are for!
@@Codewrinkles I can see your point. I'm trying to get rid of something that I shouldn't delegate to automation.
in this video you say "jimmy boggard said to not use automapper". but what he actually said is to not use it if you are against the design convention it is trying to enforce
"But does it smell like business logic?" with the pretty girl in the automapper video made me explode with laughter, thank you, you made my day))
How would this compare to writting seperate extension methods to do the mapping, leaving the Models lean..?
As I mentioned in another comment, performance wise it would be quite the same. So, in my opinion, using extension methods would also be a legit approach.
Froom a practical perspective I don't think that writing an implicit/explicit operator in a DTO is bad. Au contraire that's what a DTO actually is. However, I consider it wrong to have implic/explicit operators or assignment methods on domain models. Domain models shouldn't know anything about things that are outside the domain itself.
Just came across your content and subbed. This channel is hidden gem 💎. Now my favorite C# youtubers are Codewrinkles, Nick Chapsas, and Raw Coding. 😊
Thank you very much. These days I was lucky enough to hang out a lot with the Raw Coding guy :). Thank you for your sub. Also feel free to invite other colleagues, friends that you think might find it useful.
P.S; This AutoMapper video, even though my most popular, is not one I am particularily happy with. Take a look at the videos released during the past two months!
@@Codewrinkles For sure! Excited to learn more C# from you 😊.
very nice bro. I was a thinkific and useful hint
are you running benchmark under debug mode? if yes you should do it under release mode
No, under release. If you are in a debug configuration, BenchmarkDotNET doesn't even run.
It used to be the case that it was OK for the Dto to reference the entity, this is how I used to do it (except that I preferred using constructors rather than FromXXX methods. However we now live in the age of Blazor which means that there is an incentive to reuse the DTOs on the client. Why write them twice after all? Technically this was the case before Blazor if you had a C# server which worked with a WPF or Win Forms app but most apps were web apps. Blazor kind of closes this shortcut because there is much bigger gain from sharing the DTOs. I now write the mappings in a separate project as extension methods.
I was going to make a comment about using extension methods since then you remove that implementation detail from both the entity and the DTO and the spots where the mapping happens are just calls to a static method; increasing readability and discoverability of the code. Furthermore if a convention is established adapters to existing mapping libraries in use can be automatically generated with a minimal source generator.
Not sure it is a good idea long term to have a project referenced by every layer of the application. Even if it only contains dto.
@@gp6763 I am sure it is a great idea, I've done it on multiple long term projects and never had a single regret. The whole point of a DTO is to transfer that data on the wire, it is the contract of what is transferred so both sides must comply. If it is technologically possible the DTOs should be shared, if not they should be generated but if no good tools are available they can be written by hand
New thing learned, Implicit & Explicit operator overloading. :)
So you already knew about the implicit operator, but not about the explicit?
@@Codewrinkles Nope, I just updated my comment.
@@robertmrobo8954 I was just curious as these two usually go hand in hand.
@@Codewrinkles Yeah, you are right. Won't make much sense for one to know only one of the two.
what is your opinion on mapster?
the number 1 reason i need maper is Iqueryable projectTo
I haven't used Mapster in production projects and therefore I wouldn't like to voice an opinion on that. Don't know about other .NET UA-camrs, but I prefer to create content and express opinions only on things that I have witnessed first hand in production projects.
This is what I've been telling the tech leads about not using AutoMapper for the same reasons mentioned in this video.
AutoMapper has become a default mindset in .NET unfortunately. And such a mindset undermines critical thinking. That can happen at any level.
@@Codewrinkles You're right. I hope that all developers give up using AutoMapper because it causes more problems than it solves. We used custom mapping methods in our BlazorPlate SaaS template exactly like you did except for the explicit and implicit conversion operators. We will give them a try.
@@BlazorPlate Strongly disagree. It's not Automapper's fault if you can't use it properly. I used both, and I still dislike writing code that has no value. So AutoMapper all the way.
I do blame Jimmy Bogard a little, but he himself admitted that he made mistakes by implementing things to please his audience in the past.
@@RaMz00z I'm not throwing rocks here, but I want to point out that the developers who use AM to do the mapping logic spend the same time which is spent by the developers doing the mapping logic manually without using AM.
With the ease of use of resources on the cloud I definitely would prefer to add one or two processors than having double or triple the size of all my code on my Model and DTO and ViewModels. With huge projects with your approach instead of having some dozens of lines of code, you probably will end up with hundreds of thousands of lines of code to maintain ... Good luck with that. And about performance, if you really need to improve some mapping just project a collection into another.
On the one hand I totally get your point. On the other hand, I want you to show me those enterprises you have developed for and the CTOs and CFOs were totally chill on adding processors after processors or continuously clou resources. In the enterprises I worked for those type of resources are calculated, planned, budgeted and you can't just simply "add another processor".
In practice that "dozens of lines of code" that you'd put in a DTO for the mapping are usually placed in "Profiles" classes. Also practical experience showed me repeatedly that devs spend equally long just writing some boilerplate code to configure AutoMapper profiles. So, your argument doesn't stand, because in real projects you usually don't write less code by using AutoMapper.
Also practice shows that maitaining AutoMapper profiles is more expensive in terms of time than maintaining direct mappings.
Sure, one can like AutoMapper and the illusion of simplifying things, but critical thinking and verifying assumptions is equally useful!
@@Codewrinkles Sorry but, yes, you can just add another processor that's the advantage of working on the cloud. I don't know what you mean with "Profiles" classes, but in reality, if you have to do a simple mapping for two classes with 50 props, you have to write (and maintain) 50 lines of code (or 100 if you need a reverse mapping) while I just write one line of code, so I really doubt that is this example maintaining 50 or 100 lines of code is less expensive in terms of time than maintaining just one. Writing boilerplate code to configure AutoMapper takes less than 5 minutes, so that's pretty easy. I know for years the performance issues about AutoMapper, but the maintainability and easy of development with this lib surpass any performance issue I've encountered so far. Another thing that makes all so simple with Autommaper is cascading mapping: I don't have to implement nothing or even worry about that. I totally got your point of view, but I would never implement mapping like that ... at the end anyone is free to implement whatever feel better, it's the beauty of software engineering : there is always another way :)
True Indeed, very good information, I will get rid of from AutoMapper in our next projects. Thank you for the information.
Glad it was helpful! However, also take into consideration the idea of using extension methods to do the mappings. Choose what you think it's best for your next project.
@@Codewrinkles Sure I will also check extension method to do mappings, if you have any video please share the link with me. Thank you for your response.
Have you used Mapster? I have been using it for a while now and it's super easy to use and it seems to have better performance than automapper
I have played with it, but I didn't come to use it in a production project. Yet! :)
Great video!
thanks for the explanation
You're welcome
I prefer the way FastEndpoints does it with separate Mapper classes.
FastEndpoints is a nice library. Carter Modules also. However, I tend to not use them in production applications.
Thanks as always
My pleasure!
While developing big applications, this will make us to write more code compare to auto mapper. Right?
I'd dare to say that the idea that "with Automapper you write less code" is just an illusion.
WAY more code, hundreds of lines more, which add zero value to the project.
@@Codewrinkles Then you are using AutoMapper very wrong. It cuts hundreds of lines of codes, that is a fact.
@@RaMz00z No, it's not. It would be true if you'd rely on conventions 100%. And to do that, you'd have to name all your class properties to support flattening and all the convention stuff. Which is way worse in so many ways.
Thanks, Can you please share you git repo for this demo?
Source code access is one of the benefits ot Codewrinkles members. If you want to gain access to source code, join as an ambassador member. There is a JOIN button right below each video.
Why anyone shows how to use this dtos stuff in real cases, but just some abstract code. As a newbie i dont understand anything. How to use this in controller?
Great job 👏
Thank you! Cheers!
If your use case is that simple by all means use this video. But for me it misses a lot of functionality, mainly the the query projection when using OData. If your system is not just converting to send, but has security/flexibility/customization and your performance is more linked to how your DB query is made then -- BIG NO. Thanks for the video!!!
I have made a separate video on projections in AutoMapper and how they can optimize your app
what about reverse mapping ? using your methods let's say from dto to product
Hmm. I don't see the where is the challenge there. You can create a method for mapping, like I did with ToProduct(). Or you can still use the operators to do that.
Unfortunately you completely missing the point of a mapper: mapping many really complex objects manually is not maintainable. By the way a mapper can be used in a implicit or explicit conversion operator too.. it’s a not a mapper xor conversion operators. Moreover a object in medium large projects is tipically mapped to multiple dtos; the main object should not know about them
I don´t like the explicit operatos very much. It hides the fact that you are mapping at all. It also should not be faster than the other manual approaches, your benchmark to me look like margin of error. I think one of the cleanest ways to do this custom mapping is to create an interface similar to IEntityMapper with two methods like TModel MapToModel(TEntity entity) and TEntity MapToEntity(TModel model). Then implement that for your two types and use that for the mapping. If you don´t like it I´d prefer using the ToXyz FromXyz methods in the classes or maybe even using the constructors. Although I´d prefer the former as it´s more implicit about the purpose. Still using automapper a lot at work. It´s mostly a time saving measure. Being able to quickly map bigger objects to smaller models, flatten them if necessary and do query projections from the model to the db entity is very useful. Say if you have a 3rd party grid with filtering, paging, sorting built in it´s probably gonna spit out a query against the model the grid is using.
The only downfall or replacing a system like AutoMapper (which is acting outside of the types as a middleman) with operator conversions is that at least one of the types needs to know about the other type, creating a coupling that you didn't have before. You cannot define implicit or explicit operators outside of the type definition itself.
I can understand why this is a downside, but I don't think it's a real problem in terms of architectural concerns and technical debt. Like, I don't see any problem for a DTO knowing about the domain model or whatever model it uses to create a DTO. That's the whole point of a DTO: transfer data. Take it from somewhere (source) and transform it (in the DTO itself), so consumers can consume it. On the other side, it would be wrong for a domain model to contain implic/explicit operators to map into a DTO. The domain model should be totally isolated.
But another approach would be to create a class containing extension methods for the mappings. It would still be much faster than AutoMapper. And that would also mitigate your concern.
yeah im not sure this is a downfall. if i right click -> Find all references on a property on the domain model and no where in the code does it indicate it maps to a dto then it becomes harder to follow to code. if u explicitly map everything in automapper then this solves that problem. but the question of coupling is only a problem if its 2 way cos now u potentially have circular dependencies, and if the dto existed in some other domain that shouldnt know the details of the current domain cos then u have low cohesion.
Why not just use a plain old constructor that takes a Product instance?
The implicit/explicit cast is interesting but maybe a bit esoteric.
The reason I find mapper libraries bad is because you can’t easily navigate to the source. I assume you can’t easily navigate to the explicit/implicit cast function either.
Constructor also works fine. Extension methods as well.
also another way is to use extension methods to be direct mapping in separate files
Totally agree
Trivial, but calc should be price + (price * Vat / 100), not the other way around... doesn't affect the point of the video though!
Nice catch!
Its 2am here. Sorry if i am asking dumb question ahhah
1) This way I can transform a product into productDto. what if I need the vice-versa too? (two ways)
2) _mapper.map(products); how Can I achieve this? I mean, Transform collections.
1. On the ProductDto class you would have a method "public Product ToProduct()"
2. You would have something like this: on ProductDto "public IEnumerable FromProductEnumerable(IEnumerable)".
Nice!
I wouldn’t do any of the proposed solutions. Create a class who’s job it is to do the conversion. I believe this is called the Single Responsibility Principle from SOLID.
I see it differently. It's the quintessence of a DTO to handle data transfer from on place to the other. Therefore, it should be the responsibility of the DTO to do this. I don't see how this would violate the SRP. Quite the opposite, actually. But, sure, if you want to create a custom class for that, feel free, To me, however, this adds needles indirection, which is a code smell.
@@Codewrinkles the DTO should only be a simple data structure. It’s responsibility should be to hold a database record. The logic of how to transform the DTO into a model class should be separated out into its own class. You’re still creating spaghetti code with dependencies. At the end of the day, write your code how you want. I’m just providing a different opinion and an alternative way to approach the problem.
@@runtimmytimer And I guess we can agree to disagree. However, we are in an OOP world, classes are not just data structures. Classes are a container of state and behavior. Thinking about a DTO as "just some properties" is not the best way to think about software in the context of OOP. In that case I'd rather go for functional programming or even go to good old procedural programming.
@@Codewrinkles Just because you’re developing using OOP doesn’t mean every class needs to have methods. You’re also generalizing a programming style and applying it to a very specific situation. Which is just nonsense. One thing I like about automapper is it isolates the logic of how to map one object type to another object type into a separate class. In instances where performance is of most importance, it would make sense to use the same principle by developing a class whose job it is to do the conversion. Again isolating the logic of how to do that transformation into a single class. Adhering to the single responsibility principle. It makes zero sense to me that a DTO would have any knowledge about a model object. But hey,you’re free to write code however you want.
Yes I enjoy!!
Just use Mapster
I also felt uncomfortable about using AutoMapper since it hides stuff and configuring might be a pain. Thanks to analyzers and source generators, there are now better ways to map objects. I still write my own code for mapping though
I guess source generators also add some overhead. But that's indeed a topic for another video I guess.
@@Codewrinkles Yes. But at least they get rid of the reflection (in most cases). It depends on what it does in the generated code. Some JSON serialization or Regex parsing done with SG is mostly not worth it since you don’t gain anything.
@@marna_li What you gain by source generation is that your assembly will support trimming. Which could be an advantage for client side applications finally removing the need of having a bunch of runtimes installed by your clients without blowing up you application size. Also AOT cannot really work with reflection based code either. For legacy apps its not worth bothering with, but for a new from scratch project it might be worth dropping these reflection based libraries for more modern alternatives.
I agree. And in some circumstances in a restful microservice architecture with lots of get routes and when dtos are quite different from the domain objects you'll even end up with a lot of automapper mapping code especially if the configuration validation method is used in the CI.
What about EF ProjectTo?
Acutally I have created a video on that topic a few weeks back. It's great. And it's how AutoMapper should be used. Still there is the risk of writing business logic in the projections configurations.
I still prefer Automapper before manual mapping.
The DTO should just take Product as an input to its constructor. No need for a static factory method here.
I will default to automapper because productivity and use direct assignment whenever there is more logic needed beyond 1 to 1 mapping. These two methods are not mutually exclusive.
I really don't get the argument with the "productivity" as while leading different teams I have witnessed first hand that writing AutoMapper profile usually takes at least as long as writing direct assignments. But, of course, everybody is free to use what it makes sense. The important thing as software engineers is that we should be aware about the pros and cons of the tools we're using.
Definitely not a fan of using this pattern of operators at scale as I've actually seen it in a large monolith. Not only does it still introduce coupling on one or the other, but it also obfuscates business logic and makes debugging more difficult. Not to mention a new dev on your team is going to have a harder time ramping up.
With the rise of source generators, my opinion is that rather than encouraging the use of operators for mapping we should be encouraging devs to use source generation whether that's a 3rd party solution or something written specific for your application.
Source generators also introduce some performance hits.
@@Codewrinkles
No, they don't, they just introduce compilation performance hits, but not so much, if the generated code is well written then you will have the same performance than handwritten code, by definition
I don't think this qualifies as an alternative solution to using automapper. In fact, it is a step backwards. While I somewhat agree, we should just map properties manually, it's not because of the performance hit, it's because auto mapping with Automapper in production is often not as useful as you would think, especially when your models are properly designed.
I fully agree. And of course using implicit and explicit operators is not a good idea as well. But, on the other hand, having mapping methods either on the DTOs themselves or extension methods is something that proved very useful to me in my day to day work. Still, performance is an aspect that I think needed do be discussed.
I avoid AutoMapper and DTOs in general. Just use POCO entities and an ORM and for complex views, aggregate entities in view models, which are not part of the domain but are needed for visualisation only.
Sounds like a very interesting approach.
thanks. where is your source code (github) ?
Source code is available for Codewrinkles Ambassadors only. Join the channel memberships program as am ambassador and you'll get access to source code.
Many problems: 1 we have to write a lot of boiler code if the models and dtos have many same name and value types properties. 2 because of (1), we have to take more effort to write unit tests and it makes easier to have some mistakes, eg wrong or missing assignment. 3: we have to maintanance the order of properties in declare and mapping to make the code to clear so that not make many trouble later. 4 in my opinion, model is just model, we shouldn’t add too much dependencies and login inside, let think if a dto can be mapped to many entity model, we have to declare them all in the model classes. I faced this problem before when I have to maintance a very old project and what I can say is bullshit
You didn't mention Extension Methods (would be my choice)...
Nope, not in this video. But extension methods is also a very good way to achieve the same.
I'm not a fan of AutoMapper but I do like using MappingGenerator
Считаю использование операторов неявного приведения типов плохим подходом. Они запутывают код не лучше чем автомаппер. Да разница в скорости там по сравнению с ручным маппингом всего 1-2%
Awesome
I must be old. No discussion of a simple constructor?
var pDto = new ProductDto(product);
It seems like good OO practice has been poisoned by fancy addons (AutoMapper). Add the VAT computation to the Product class and you constrains mapping to the mapping class and business logic to the business class without compromising speed.
Too bad you mention OO Practice when what you discribe is actually bad practice...
What you gonna do, reference all your DTOs in your Models ?
In the model Product, you'll have all the different constructors for all the derived Dtos ?
No, the right way is too use a class to do the two mappings, separatly.
@@RaMz00z It’s the exact reverse. The DTO’s reference the model. Read the code until you understand it.
Edit: I just reviewed the video and you actually suggest implementing a copy method. That will produce the exact same kind of dependencies you mistakenly suggest a DTO constructor would produce.
@@RaMz00z Since you’ve hidden my earlier response, and lauded yourself for being insulting, here’s the reply again:
It’s the exact reverse. The DTO’s reference the model. Read the code until you understand it.
Edit: I just reviewed the video and you actually suggest implementing a copy method. That will produce the exact same kind of dependencies you mistakenly suggest a DTO constructor would produce.
@@jasonfreeman8022 I did nothing and I'm not insulting, dude.
Just mapping doesn't go there, especially if there is reverse mapping.
Great 👍👍
use dapper instead
How to make a video about how doing this kind of shit is so wrong. AutoMapper... a way of doing stuff you should be doing yourself and then expecting good performance.
Use Mapperly
Please don't use implicit operator cast for business logic, make it explicit, it will be eaaier to read code.
Agree with that.
bad take, you dont use automapper for performance, you use automapper as a mechanism for enforcing and maintaining trustworthy contracts. Minor performance impact is a small price to pay over a single production bug caused by a property manually mapped as always null, etc.
Sorry, AutoMapper causes much more bugs than manual mapping. And the bad part is that it's even harder to find those bugs as compared to manual mapping.
Automapper is a pain in the ass, no benefits, just a lot of work to conform to the librarys way of thinking. A lot better is to manually have a method which maps from the object to the dto. Simple, efficient and no headaches, and full control of the code.
No No No to the implicit operator stuff. This is not what they are for. This is twisting a language feature to a purpose which will be foreign to maintaining developers. And there's no compelling reason to do it. The ToXxx() methods were fine. The only non-standard use of implicit operators that I have seen which was acceptable was to implement 2-member discriminate unions (as C# does not have them natively). I agree that Automapper is mostly unnecessary. I only like it where my objects have 10+ properties. Then it is easier to map than manually assign members. And that was its original purpose.
I also agree that using implicit operators is not the best idea because it makes everything look like magic.
Really triggered by the video, that I had to comment even. First, those performance numbers that you are showing are a joke. If they make a difference in the program that you are writing, then you should not be using C# at all. Second, the point of Automapper is not that you are writing the code faster, because good code is always written slow anyway. It's about the lines of code that you need to maintain after that. And with Automapper you are indeed reducing a big number of code lines that you need to maintain. And third, that "code smell" that you are describing where you put business logic into Automapper projections, is actually not a code smell at all. It's actually the right place to put it, since that is the place where you are mapping from 1 model to another. Which is essentially the same that you wrote in your mapping functions, with only difference being that in Automapper profiles you have a lot less code.
If you think that putting logic in the mappings is the right way to go, there's not really anything to discuss...... The moment you so dogmatically propose a theory that's even rejected by the library's creator, there's nothing to say.
@@Codewrinkles I'm not saying that you should put "business logic" in the mapping profiles. I'm saying that whatever code you would put in your alternative mapping methods can and should be placed in a mapping profile. So, if that tax * price calculation is wrong in the mapping profile, then it's equally wrong in your mapping functions. Cheers!
So basically automapper uses reflection. Everyone knows that.
ты же лучше не сделал. с чего ты взял, что ДТО должно знать о домене?? А если у меня на одну сущность приходится штук сто моделей с разным набором полей? а то, что ручное сопоставление полей быстрее маппинга - очень очевидно. В общем, видео не только бесполезное, но и вредное. Спасибо, что губите нас