AutoMapper example projects with mapping profiles
Hi all,
Rather simple question (If you can even call it that?)
I'm just looking for people who have worked with the AutoMapper library to dump a link to their open-source projects here if anyone has or anyone knows of an open-source project that uses it. I already have an understanding of the very basics so dont need any teaching on how it works as such.
Been playing around with it but want to get a "feel" on how best to implement it in my application without the codebase being a giant mess. The plan is for it to map between EF database objects and DTOs for a few different APIs and a WebUI.
Prefferably good, clean examples of implementations I can take a look at.
Any/all input would be awesome 😄
26 Replies
First thing would be. Are you really sure you want to use AutoMapper?
Debugging it may cost you more time than you save in the long run.
And did you consider alternatives like Mapperly, which source generates the mapping methods.
there is nothing wrong with automapper as long as you are aware of the tradeoffs between it and other solutions.
the most straight forward way is to set up a mapper profile for each of your entities. I usually declare them in the same file.
https://docs.automapper.org/en/stable/Configuration.html
I usually scan the assembly to auto register the profiles to the mapper config.
Nah automapper is pretty terrible, might as well just use a dynamic instead of DTOs, it amounts to about the same thing
I've only used it when forced, and then we just explicitly map every property to avoid the worst of the issues, which of course makes it completely pointless
I mean, using Automapper or any other mapper, is a design choice and you have to be aware of the tradeoffs. AutoMapper is only bad when it's misused. The biggest valid criticism is that it moves some errors that would conventionally be compile-time errors to runtime errors, which can make debugging a headache (mentioned above).
That being said, on most projects I think AM is probably not needed. I would actually recommend just writing the maps yourself.
Mapperly if it does a similar thing could well be a consideration
The main importance is that I can map one array to multiple parameters
E.g. a list of one-to-many record links in an EF object
I will need to map that to not only an array of the dto for that object, but also set another property in a dto to the count of that array
If this makes sense
Another example is that I will need to store an index for an array of strings stored internally, and will need to convert that into a string in the dto
So as long as it has similar flexibility in that regard to automapper it's certainly something I can consider
I guess I could do but I ideally wanted to avoid writing out all the object mappings manually, there are a few properties that have to be mapped differently but the vast majority are named the same and can just be copied across normally
Some objects have around 20-30 properties as well so figured it would be quite tedious to manually write it all out
Though at least that way the compiler would pick up on property mismatches I guess
that's exactly what AM was made for. Convention based mapping with minimal/no additional transformations to the dest props.
I'm not sure how you can avoid writing the profiles if that's what you are referring to.
Umm not necessarily, just looking how to organise them in a project sense
Without ending up with a mess of CreateMaps that's unmanageable
But I'll take a look at mapperley because I'm all for compile time stuff if it has the same functionality
(I have a lot of dtos)
Pretty much put it in your entity class file or have a single file for all of your maps. I prefer the former. I believe mapperly does.
Have you got an example of how it would work in the entity?
Since profiles would have to inherit profile
remember that either you make a map for every field or if you rename a field the mapper will crash at runtime because you maybe forgot to add the map or rename the fields in the mapped types
with a sg mapper this doesn't happen, i would say this is not that small of a tradeoff
So do you just inherit that into the entity class?
(At least this is my understanding)
And yeah I see this, I guess it's less that it will crash though and more that it just won't map the property
So it will have whatever the default value is
(Likely null)
it depends how it is mapped
which flags you use
also there are matter in organizing profiles if you have inheritance between projects and such
and if you have converters or custom stuff
AND ALSO mixing profiles with logic keeping a profile "clean" is... not good
Ohhh right, that makes quite a lot of sense actually
For some reason I've never considered multiple classes in one file, I always try to avoid it usually
It's usually a good idea to
Also yes there will need to be some logic in some parts potentially
As one of the apis isn't json and is raw binary for another application which I can't adjust
So it may want stuff like array lengths separately
And total record counts
However it seems pointless to store these manually in the database
I'd go a step further and say it sounds like a bad idea
Yeah well you gotta keep it "in sync" with everything else :P
Which seems like a recipie for disaster
Main one is a scoreboard endpoint, the client needs total records returned based on filters, total in database as well as, if a specific record is requested, the position of it on the scoreboard relative to the entire database with other filters/orderby applied
The latter I did have some working code but would have to dig it out, it involves storing an IQueryable and getting the index of said object in a query before filtering the IQueryable down further and then limiting to 30 results and fetching the actual data
It involves evaluating the query twice though which I need to look into and see if there's a better way to go about it, going off on a bit of a tangent now though :P
if it's a one shot project with just one principal domain i'm not against using automapper
if this has to be a project maintained for 20 years by multiple people with future evolutions then 99% i would stay away from it
yeah I'd recommend Mapperly if I had used it before, in theory it seems much safer and better than automapper, I'm just not sure if it might have other problems in practice.
Turning compile time errors into runtime errors is ... hard to overstate how big of a problem that is, it enables errors that would be nearly impossible to produce without it. And even worse that it sometimes doesn't even cause errors, just bad data, that you never know about until one of your clients tells you about it writing all the mappings manually just has to happen once and is safe and maintainable forever after that. I'd be most interested in a 'source generator' mapper that just generates them once, on some command, and then they're real code that you just have around like anything else and maintain as needed If you're set on automapper, the way I've always used them is just one Profile for the app or project or service or etc. It gets especially rough when you start needing different services to map things in different ways, of course, or if you start designing your logic around automapper so then you have to start coding complex conversion logic into the maps But notably, one thing I've found automapper useful for, is it has a ProjectTo thing that works with EF, which can be neat for performing an efficient query that selects exactly what you need from the database. Though that skirts close to a repository pattern, but it can be very nice to have all your DB queries updated by just updating the profile, or sometimes even just adding a new property to the DTO, and it ensures that it gets selected out of the DB once added I don't think it's generally worth the tradeoff, but that should be enough for you to do your weird complex mappings from the database if you want to. Though when they get weird and complex, automapper should almost certainly not be used
Turning compile time errors into runtime errors is ... hard to overstate how big of a problem that is, it enables errors that would be nearly impossible to produce without it. And even worse that it sometimes doesn't even cause errors, just bad data, that you never know about until one of your clients tells you about it writing all the mappings manually just has to happen once and is safe and maintainable forever after that. I'd be most interested in a 'source generator' mapper that just generates them once, on some command, and then they're real code that you just have around like anything else and maintain as needed If you're set on automapper, the way I've always used them is just one Profile for the app or project or service or etc. It gets especially rough when you start needing different services to map things in different ways, of course, or if you start designing your logic around automapper so then you have to start coding complex conversion logic into the maps But notably, one thing I've found automapper useful for, is it has a ProjectTo thing that works with EF, which can be neat for performing an efficient query that selects exactly what you need from the database. Though that skirts close to a repository pattern, but it can be very nice to have all your DB queries updated by just updating the profile, or sometimes even just adding a new property to the DTO, and it ensures that it gets selected out of the DB once added I don't think it's generally worth the tradeoff, but that should be enough for you to do your weird complex mappings from the database if you want to. Though when they get weird and complex, automapper should almost certainly not be used
i have tried mapperly, it has features, but the point of it is keeping it simple; when you make a map you can immediately see the generated code when you F12 it, but like other source generated stuff (refit for example) it happened to me that code was not updated and compilation gave errors (with various tries to make it return to work like cleaning solution, compiling n times, restarting vs, etc)
in the last year errors like this got to almost 0, anyway
Yeah I will give mapperly a try thanks and see what its like.
As long as it can do more advanced mappings that automapper can
Also tbh looking at mapperly if it generates everything at compile time probs also a lote more performant than reflection too
Has anyone got an example Mapperly project I can use to look at implementations?
Nothing much to look at tbh. The documentation is also quite good.
Yeah think im getting the hang of it thanks all
If I can properly figure out mapperly looks like it might be a great alternative to automapper actually!
its nice because you can see the resulting compiled code as well, so I can see what its actually doing behind the scenes so I can verify its mapping correctly
I cant remember the person who recommended Mapperly but thank you 😄
And also if im not mistaken, it should also be faster than automapper?
Because it looks like the resulting compiled code is just the same as if you manually wrote mappings line-by-line in a class constructor etc
Yes it is considerably faster than AutoMapper, because reflection is kind of slow.
It honestly won't really matter in most of the projects, but nice to have I guess.
exactly, given a baseline of performance, the most important part is having understandable code