The Best .NET Mapper to Use in 2023

I am new to this area, so let me ask: Are DTOs the same as View Models? Or do they have different objectives? I've tried searching, but it's getting more confusing. Some say they are similar, while others claim that their purposes are distinct

In Mapperly how do you do simple tweaking?
For example, imagine I have a boolean on the model, and a {"Yes", "No"} string on the viewmodel. This is very easy to do on AutoMapper. But where are the entry points on Mapperly to allow to do this and how to do it?

I need more documentation about Mapperly! Using the mapper for generating new data types, fill a dashboard dto, etc.

If I'm not supposed to make database calls in the mapper then how am I supposed to resolve lookups?
Let's say System A has a table of users with unique email addresses. System B has a list of users where the email address is unique, but there is a user ID column in the table which the API requires me to use to reference the desired user. I have to resolve the user by the email address. Where would this transformation logic go?

Been trying to use mapperly but kinda got stuck on the circular dependencies, even with their annotation, my case seems to be more complex with some methods using a custom mapping and others not :/

Decided to try mapperly following this video. I've always tended to write my own mappers rather than using something like Automapper in the past so it is my first foray into automated mappers. Unfortunately, it doesn't look like it supports doing something like this from what I see on the website where you have a generic type within both the DTO and the model and want to define that at the point you are mapping:


public partial class MapperlyMapper

{
public partial Email<T> Map(EmailDto<T> sendEmailDto);
}

public class Email<T>
{
public T Message {get; set;}
}

public class EmailDto<T>
{
public T Message {get; set;}
}

Ive only used automapper and holy shit I hate it 😊

I’m less concerned with mapping speed and more concerned with things like is it type strict (nullable vs non nullable) or will it do some intelligent cast/conversion

I don't know why byt in my laptop Generated_Map is 723ns and ManualMapper is 366ns.... AutoMapper is not running at all )
I wrote code from video, not your repo.

Mapping generator avaliable only in paid version... sad

I used to write my own mappings but that got laborious quickly so I switched about 5 years ago to Automapper. I've always found it ok but my biggest frustration with it though is it doesn't tell you when it's not going to work, it'll build with mapping errors etc. Mapperly looks good so I'm going to take a look at that one now. Thanks for the video, very useful.

Mapperly is new to me, and I was surprised by its results. I think it'll be my next mapping pet😎.

Definitely an interesting comparison. I have been using Automapper for yonks but have been considering alternatives to see what is out there that might be easier to set up yet still support everything I do. I have been considering Mapster for a while and will have a look at Mapperly.. I'm honestly not a fan of code generation as it tends to muck up things like getting it excluded from code coverage. Though I'm less of a fan of things like convention-based / reflection, so in my case it's a lesser of two evils. Ease of explicit configuration is important to me because often I am flattening things like entity graphs, and want to ignore some values that will end up being loaded as references. I am also looking at details like support for projection, so integrating into things like Entity Framework and it's IQueryable implementation.

Does not Entity Framework count as a mapper? Why not include it in the options?

if you can use automapper, you have an useless layer.

I have been using AutoMapper for a long time now. I think I started using it back in the days of the static API.
HOWEVER, I have reached a point where I am prepared to dump AutoMapper as the maintainers of the source do not write very good documentation to explain certain things and even have gone so far as to just outright delete a question they didn’t like, saying it should be answered on Stack Overflow instead, which is just dumb when I was asking them for clarification on a point in their documentation related to breaking changes they introduced in version 12 that are poorly explained. One thing I will say is that they have a great method you can call in your application startup when you are configuring your mapper. After you have registered all of your maps, you can call the AssetConfigurationIsValid method. This ensures you don’t have any properties added after the fact that can’t be mapped or are missed. Very good thing to have, especially in your development environment.
All that being said, I am going to be looking closely at Mapperly to see if I can swap out AutoMapper for it. I admit I have included some business logic in my mappings in some limited places. I am going to be reassessing that approach in the future.

I don't agree with the statement that the fastest mapper is the best mapper. 🤔Instead of chasing nanoseconds their features, how configurations are setup and how easy they are to work with is more valuable. Mapping a DB entity to a DTO is mostly quite simple. Their disadvantages can show when you want to map the other way around; from a DTO (or child DTO) to a DB entity, especially in the case of EF Core if that entity is already being tracked.

Take your mapper and put it in the trash. Thank you goodbye.

Mapperly definitely looks great. How can a change in DTO be reflected using Mapperly, will it auto update the generated code while I re-build?

Mapster also has source generated version.

In our project we map manually between db => bl => api because the dto can look different or sometimes we have different dtos, penending if an object is in a list or a detailed view. Also mapping from bl => db we want to update an entity, not creating a new one. Those are som reasons why manual mapping is required in our case.

I use my custom mappers :))

Mapperly looks awesome, as performant as manual code without having to type much

Will be using that going forward, thanks Nick!

@Nick Are you really ok with using random libraries in your enterprise software? It doesn't sit well with me that I could be using a package that may as well contain code that would give my entire database to some Nigerian prince or delete "/". And I'm not even refering to obscure packages either. I don't think even popular projects like MediatR or Dapper can be said to be 100% safe.

Mapper are for Millennials+ and lazy people 😂

I am relativly new to that mapping issue: what about explicit and implicit operators and their performance? Shouldn't be they mentioned as well here?

@Nick: Do you have a video about writing your own mapper?

Honestly if mapperly could make a vs plug-in to scan the solution for where the mapper is being invoked, auto discover what types are being mapped, and update it’s partial class automatically, that would be incredible.
A composite of auto discovering mapperly, with mapster as a fallback if mapperly doesn’t have a mapping, would be the ultimate.
Do I have a map for this? Ok, mapperly. No? Ok, mapster.

It’s got to go to mapster if it can map anonymous types without configuration

Mapperly is blazingly fast :)

Friends don't let friends do automapping. Do manual mapping or use a source generator to generate explicit mapping code during design time.

Thank you for this. I've always created my own custom mapper but am going to implement Mapperly in my current project.

for big system with high trafic => manual mapper inside model class.
for small -> medium system => automapper.

I have never experienced a practical benefit long term from automatic mappers, personally. In theory it would be nice if everything was automated, because the Dto and Model objects normally start in sync. But in practice they eventually diverge to the point that you usually need extra metadata at some point to do the mapping(because the requirements of the Dto don't always match the model types), and at that point I don't see the benefit of using config features of the mapping library. My tendency would be to just start with something like Mapperly and if it breaks or won't work for the use case, it is probably time to swap that mapping method to a manually written one.

Automatic mappers provide an excellent way to accidentally overfill your DTO with sensitive information (given you use the same type for requests and responses which you'll probably do). Also, they introduce unnecessary "magic" to your code to make debugging more difficult, and all of this for automatizing the simplest task ever: mapping. why???

I wonder how Mapster Code Generation approach would have faired.

Great video, extensively use automapper in the way you describe, view to viewmodel but definitely considering the move to mapperly because of the source generation.

Mappers are only really required with external or legacy databases or libraries. Aside from that it a good argument for consistent variable naming conventions across code or single developer code bases by developers who are OCD about naming. :-) (I am: I name the same objects consistently across a codebase so I can search and address and refactor cross-cutting concerns easily!)

The best mapper to use is no mapper. Didn't watch video yet, but you are unlikely to change my mind

Automapper is a good object structure validator. Using built in validate in unit tests so i am sure that external dto after nuget update is still good for my domain objects

Just don't use mappers. Ever.
Make a specific constructor for your needs.

I've been using automapper for like 15 years... never occurred to me that there would be something as easy (or easier) - that was quicker - ok - thanks.... mapperly was just added to my project !! (and good to know I use it correctly - ...

Mappers? No thanks 👌😉

Benchmarkdotnet only does benchmarks sequentially (not in parallel). But I wonder which approach handles better under load. It would be nice to see this done with NBench w/ RunMode = RunMode.Throughput, this would run parallel.

I disagree on the part of not mocking the mapper in your unit tests. We create a separate unit test class for testing the mapper profiles. IMO, this allows for cleaner tests and makes it very easy to catch any issues you might have with your mapper, instead of having to determine if the test failed because of an issue with the method or an issue with the mapper. And if you have multiple methods using the same map, you don't get multiple test failures. You just get one failure for the mapper test that is testing that particular map. I do agree with you on not putting complex logic into your mapper. We, unfortunately, have already gone down that path, and every time I see it, I cringe a little bit. Hopefully some day in the future we will get time to refactor that.

Thank you for this video, I didn't know about all the different mappers library since we only use AutoMapper.
Well I will consider looking into Maperly lib, it looks quite interesting, and tell about it to my collegues.
Have a good day 🙂

Hey Nick, Thank you for the great content. You did a video earlier about Mapster and it's source generating feature which I remember it had better performance. Why didn't you include that in the Benchmarks also? 😁

I used to go with automapper but then change for mapster which is way faster .... did not know about mapperly, i'll give it a try .... Thanks for that great insight on mapping tools

Mapperly doesn't seem to support EF projections, so that's a huge deal breaker for me. Using AglieMapper today, and happy with it, but it's a little worrying that neither AgileMapper nor Mapster (that I was planning to try after this video) has not been updated in over a year.