The Best .NET Mapper to Use in 2023 

I haven't used mappers. But I was thinking pretty much the same problems you listed.

But if you have your SpotifyAlbumDto and SpotifyAlbum, and each of them have some Convert() method from one the other, then you have strongly coupled them. They must not be able to live in separate projects because that would mean a circular dependency reference. And if somebody would get tempted to put clever conversion in the mapper... they would also put it in this static Convert() method... no?

Which is exactly one of the key advantages of Mapperly. Since it is source generated, you can actually view and debug the generated code just like the code that you write manually.

@@paulkoopmans4620 If you are doing conversions you want strong coupling in most cases, you want it to break if you rename a function without changing the mapper, otherwise you risk the code breaking in production. You COULD catch this with good unit test coverage, but that requires you to do the tests the right way as he said in the video, having the mapping being able to break silently can be very costly and time consuming. I have had that happen which is why I stopped using automapper. Sure if your the only dev, or if its a small, very tight team, you probably avoid breaking it, but if the team grows, or if the project is big and have lived for a long time, like a decade or more, there will be ample opportunity to miss some dependency and suddenly a price is 0 at the wrong time. Tracking that down, especially if its some edge case can take hours or days eating up all time you save by not building those tight coupling methods, and at worst its also cost you money and or customers. When used for ORM mapping from a database or from external json, I do use them since I will make sure to verify the data, I usually do not trust data from the database opr from external sources, even if I know I put it there because I cannot be sure that no one else made changes to that data.

@@paulkoopmans4620 They could put clever conversion logic in the converter, but not to the same extent you can with mappers. With mappers you get full DI dedicated to just mapping, I’ve seen people literally inject a DBContext into the mapper profiles and use it during the mapping, which is far far worse than anything you could do in a static function. You don’t have to strongly couple anything, you could use interfaces and separate objects to contain the conversion logic, allowing for all aspects to be decoupled pretty easily if you really wanted to (which I never have)

All that is supported by all mappers. The critical thing is performance and setup. You can use that knowledge to pick the one that works for you.

On that topic, for me an advantage of AutoMapper over Mapperly is fluent configuration part. It's simpler to maintain, easier to read and more flexible in my opinion than attribute-based configuration which seems to be the only approach available for Mapperly as of now. While I agree that you should not have a lot of logic in your mapping layer, small things like different naming, ignoring fields or mapping from nested objects will add up into ten-s of attributes for a single mapping and code starts to look unpleasant.

​@@nickchapsas you did start by saying you would compare how easy they were to work with, and that's where this request comes in.

@@nickchapsas I love that you're very passionate about performance. Though I feel like most developers would be willing to sacrifice some performance for reduced development and maintenance costs. Everything is about circumstance of course, but at least for myself, I'm not concerned with the difference of microseconds if the benefit is more something more easily created and maintained ;) I have to admit I've never seen the need for mappers in what I do, and try to use a single set of models whenever it is appropriate. (Shared libraries, linked file references, etc)

@@b33j4y Can't agree more.

But tell your boss you used manual mapping

Yep, I was thinking about the same. A mapper which just takes properties 1-to-1, yeah that's simple. On the other hand - why do we even do mapping? To decouple the domain from the UI for example. But then - the correctness of the mapping relies on the structure of the mapped classes to be in sync. So if you change/add a property in a mapped class, you need to do the same in the target class. How is that decoupling?

Did you copy paste your class in the chatbox?

@@dputra Yeah. I give it two classes and ask it to write the mapping between them. Sometimes I give it a simple example if it's struggling

That sounds a LOT better. Mappers are supposed to reduce work or boilerplate but it makes it a lot harder to find what is referencing that code. Manual mapping and getting ChatGPT to do it for you sounds like a great approach.

Mapster supports code generation as well.

I'm not a fan of explicit/implicit operators because they re not as obvious, but the ToX extension method is my mapping approach of choice too

I prefer the ToType and FromType approach, and now with static interface methods is even better

I absolutely hate implicit and explicit operators for mapping because they are not obvious. None of these objects should know how it can be mapped to another object so for me using them is a complete no-no. I prefer extension methods for mapping so something like "ToResponse" for example. It's way more obvious when used and way more debuggable.

Two biggest things are: - You get immutability since you copy the data. This is important if you want to make a clear distinction when moving data between layers in your project - You're not tied to any particular set of properties. Mapping between two models with identically named properties isn't the only use case for mapping. Very often that's not the case. Tying yourself to an interface only couples these layers more since every change, such as name change, needs to be reflected in both the interface (which can act as your DTO) and the origin class. Interfaces don't really fit in here since they usually don't solve the problem mapping does.

My thought also, just the fact that it will have compile time error is the key feature. I have used automapper before but after having been bitten by property deviation over time (the project evolved over almost 16 years), i started to avoid them, any time you save developing you are likely to loose once you need to start debugging, or worse, the code breaks in production costing real money and or customers. But I will need to look into this Mapperly, it has the potential to make me reconsider :)

Mapster supports it too and Mappely is compile time so your code won't even compile if you've messed something up

It totally does. Though using static class and not allowing reflection.

Just checked, it does not seem to have any way to enforce that all target properties are mapped or that all source properties have a target, which means that a change in spelling can still break the mapping :(

Don't think it supports it. But Mapster should.

No because they are a terrible way to do object mapping. Even if they were the most performant way to do it, this they aren’t, they should never be used for this