Can I use Mapperly with dependency injection? If so, how? and what are the advantages, like can I use IMapper?

[OTonGitHub]

I love that it's source generated but, should I even be using it with dependency injection? if not, why not?

[slang25]

My 2 cents; mappers should be static classes, as it reinforces their nature. i.e. they don't have dependencies of their own, and don't have side-effects.

If it feels like you want to have it behind an interface, usually at that point it's a sign that the idea of a mapper is misunderstood, or the functionality that is being added belongs somewhere else.

[latonz]

Thanks for the excellent answer @slang25. One thing I want to add: In rare cases mappers may have a dependency, for example to implement an object factory or to provide a format provider. In these cases it can make sense to manage the instances of a mapper with DI. But a mapper should almost never contain any logic, despite dumb object to object mappings. A dependency is usually a sign of too much logic in the mapper.

[OTonGitHub]

gotcha gotcha, that's kind of what I was thinking, cuz either way the functionality of a mapper should be minimal enough and not involve business logic beyond runtime/language-based optimization that it does-not testing directly on the functions it provides besides transformation using the generated code or be complex enough to have multiple implementations right?
I'll follow the guide and just use static classes, then I am honestly sometimes just mapping 1-1 simple dto's.
Thanks so much again for clarifying.

but if this is the generally accepted philosophy behind object mappers, why is AutoMapper so popular yet comes with a huge range of features.

And lastly, the benchmarks usually show that Mapperly is slightly faster than manual mapping, can you help me understand why that is? I have an idea that it uses .net source generater to create the code during compile time, reducing runtime overhead, I think I get it but is there like an example code or something somewhere, I want to understand this more. I am quite interested in this topic I newly found.

[slang25]

AutoMapper has been looked after really well and has had pretty constant improvement since it came out, I think that has a lot to do with its success. It also fitted what people wanted at the time. AutoMapper started out with static APIs, but then went to interfaces and DI, and eventually removed the static method, however I don't think this would have happening if source generators were an option at the time, as everything had to go through a single Mapper.Map<TDestination>(TSource input), this meant that a single application couldn't define different mappings between types.

On benchmarks, the benchmarks quoted in the docs are defined here, and as you can see the manual mapping is using .Select(...) for collection projections, and I think is how reasonably how you would do it by hand. Mapperly writes readable code, while favouring performant code, so it will avoid LINQ for projections, and use the optimal collection initializers for the types being used. This reminds me a bit of AutoMapper in that it used to produce a faster DataReader implementation that I could by hand, but it turned out the saving was from it using ordinal indexers into the reader, whereas I was using names. I could obvious have written the same code to match the performance, but because it's auto-generated, it can go the extra mile of making it that extra bit faster. Going back to Mapperly, it has lots of these types of optimizations baked in (for example like how it can access private fields with no cost if enabled).

[latonz]

As @slang25 pointed out Mapperly will never be able to generate code that is faster than highly perfomance optimized manually written code. But in reality, for a lot of use-cases Mapperly generates somewhat optimized code one probably wouldn‘t write manually with a „dumb“ approach while not optimizing for performance.
Overall we try to keep a good balance between readability & performance of the generated code and maintainability of the Mapperly source.

[OTonGitHub]

I understand now, I am looking at how the generated code makes these optimizations, I never considered it could have this much of a cost when I did mapping manually but was always aware I could tweak it a bit more. It seems mapper is perfect like that, of the 3 "times" in development, I guess this is a good balance between runtime & code writing time.
I want to look at more examples of the generates source and maybe even use some of the same techniques when I do manual mapping for simple objects. It's quite interesting.

Really appreciate everyone who replied and thank you.