Stop Using AutoMapper in .NET

Hello, everybody. I'm Nick, and in this video, I will explain why I don't think you should be using AutoMapper or almost any mapper in .NET and instead use manual mapping.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[sprez]

We mock AutoMapper but not in the programmatic sense

[john_mills_nz]

10 years ago I was working on a large project that used AutoMapper and it became very clear to me then that it was an anti-pattern. More often than not, it creates more problems than it solves.

[thedmb]

AutoMapper helps a lot to catch mapping errors.

Imagine you have an entity and DTO. At some point in time, you need to add one new property or two. You add them to DTO and entity, but forget to modify the mapping method. You end up with a bug report from the customer.

Here is what we do:
We write a single unit test, which creates an instance of IMapper followed by adding all mapping profiles using assembly scan. Then we call AssertConfigurationIsValid. Test will fail if you have unmapped or incorrectly mapped properties.

With CI configured to run unit tests, you get your application mapping tested early.

[thebitterbeginning]

Been coding C# since 2001; have never used an automapper. The concerns you shared here are important; thanks for sharing.

[LoftyCuber]

We have a project with about 50 classes that can all be serialized and written to a file. Overtime we started getting backwards compatibility issues as the older saved files were out of sync with new versions of these classes. We ended up introducing a serialization layer that handles mapping older properties to the correct new ones. We deliberated between custom mapping and using AutoMapper and in the end decided on AutoMapper. It was simple to set up, especially for the 80% of the classes that had no backwards compatibility issues, and allowed us to inject some needed services into the mapping without having to write our own custom mapping framework. We had a team of junior devs at the time and we found it easier to teach them AutoMapper than to have them write that custom framework. Our project already has pretty good unit test coverage so of course we added tests for the mapping as well. We haven't had any issues with the mapping at all. I can see why you wouldn't want to use it, but I think it's saved us time and the client has been happy they haven't run into backwards compatibility errors in a long, long time.

[alanbarber]

I worked on a classic n-tier project once many moons ago and they insisted on creating a version of the data objects for each level of the system. The API had their viewmodels, the business layer had business objects and the data layer had the EF data models. AutoMapper was plumbed in at every level to convert the data objects back and forth as data flowed up and down the layers! It was crazy and so annoying!

Imagine calling a getuser api, that calls a getuser() function on a business layer user service that called a getuser() function on a repository. The repository the wrapped around EF would return a DB User object to the user service, that automapper would convert to a BL User object to return to the controller that would then user automapper to convert to a ViewModel User object to be returned to the frontend!

[kevinlloyd]

After working with AutoMapper for years, we've migrated to Mapster and here's why:
You _can_ use it with no config files. One of the issues I have with "AutoMapper" is that I needed to create all those mapping files, even if they were all using the default mappings.

There's a rule on the team that says no custom mappings. Therefore you're forced to use the mapper for the default things (1-1 mappings, flattening, etc.)
The beauty of not needing mapping files, is that there's no place to do bad things.
If you need something custom, then we build an extension method.

The other rule is, only user the mapper for goin from Domain to DTO, never the other way around (too many changes of things getting nulled out where you didn't intend).

These rules have resolved the vast majority of AutoMapping issues.

[soniy]

In our company, we mostly use an automapper because of the projection of SQL queries, which greatly simplifies the calling code in conjunction with repositories
According to our research, no other mapper analogues provide projection functionality

[meta]

Thank you so much. I agree with everything you said here. I see myself getting frustrated when working with other C# devs who tend to over-complicate things and use fancy tooling while I tend to keep things simple as much as possible. Auto-mapping is definitely one of these things.

[Xastor]

I inherited a project using a lot of AutoMapper (from database models to json models and vice versa, from database models to view models and vice versa, etc) basically all object transformations were done using AutoMapper. Honestly, it's been nothing but bugs. I had a situation where it was implicitly mapping an object into a string that was not even used anywhere and the only error I saw was a null reference exception sometimes, took me a full day to track that one down. I abhor implicit behaviour and runtime errors and since moving to .NET 8 I've just been changing everything to records, using the required keyword, and everything has been so much simpler. AutoMapper seems to me like a solution for a situation where you have objects with a million properties that are mostly the same, but that's not how you should be fixing that, and while it may reduce the total amount of work for a fire*and-forget project, any project that is actively worked on will pay interest on that and end up being more work than just manual mapping.

[peterzbinden]

One big advantage Automapper has over Manual Mapping is that you can set up a very simple generic Tests by calling 'AssertConfigurationIsValid' on your Configuration. This will ensure that all properties in your Target Types are 'taken care of' either by having a implicit/explicit source or an explicit ignore. This way, 2 years from now when Junior #69 joins the project or a different dev has to take over and 'busines just wants him to quickly add a single property' the tests will show that adding this property in the DB-Entity alone is not enough, but also needs to be added in the different DTOs, DB Query projections, Business Entities etc. whatever system you may have.

[MagicNumberArg]

We started migrarion to Mapperly this year. The more we do it - the more people like it.

[cdoubleplusgood]

"Anything that moves compile time errors into runtime errors should be discarded."
I generally agree. But doesn't this also mean to stop using DI frameworks?

[frossen]

4:02 the passion displayed here is how i feel about these things aswell! Move as many things to compile time as you can, therefore use mapperly a source generation mapper, use strict mapping to ensure you never miss a mapping again (this is a benefit over manual mapping) and turn those warnings into errors with your .editorconfig or the likes.

[stoched]

9:05 Yep, it's like the slippery slope of OO hell I always see in Java projects with type abstractions. Working on a large project for years all of those clever things you come up with you will literally forget then you have to relearn everything you did. Keep it as simple as possible always and it will usually be the best solution in the long run.

[XplodingKitten]

I'm not against of mappers and I still use them in my projects. But I totally agree with the first comment (compile vs runtime errors). So, I've switched from AutoMapper to Mapperly which is a source generate based mapper. It is capable to detect some errors like unmapped property, required properties, or something else. I do not add any logic to mappers and manual code looks like a lot of boiler plate code, so I can generate it.

[Masteroxify]

We use AutoMapper - More problems than benefits.

[ozsvartkaroly]

Thank you Nick!
After getting inspired from your video, in our company I proposed that we stop using automatic mapping libraries and it seems that everyone is on board with this direction after I presented them your points (as well as others, too).

[BenMakesGames]

love all the advice here: prefer compile-time errors over runtime error, keep related code together, and KISS.

[DanTheManSoCal]

I LOL’ed with the “password encrypted in the mapper…Jesus Christ, what the hell!?”

Well-said and thank you Nick. I 100% agree with this. I’d rather struggle with the less complexity of manual mapping of even a large class rather than chase down the invisible runtime issues and scattered mapping logic that ensues when using automapping libraries / services.