Jimmy Bogard is the creator/maintainer of Automapper.
-
DO NOT use AutoMapper except in cases where the destination type is a flattened subset of properties of the source type
-
AVOID using AutoMapper when you have a significant percentage of custom configuration in the form of Ignore or MapFrom. The "Auto" is for "automatic" and if it's not "Auto" then don't use this library, it will make things more, not less complicated.
-
AVOID before/after map configuration. If you have to do complex mapping behavior, it might be better to avoid using AutoMapper for that scenario.
Excerpts from his replies on Reddit:
-
The cases where it's useful aren't that many compared to where I actually see it being used. I built it for a very specific purpose and if you're not trying to enforce a convention, it'll just add complexity and indirection.
-
Even in cases where I do want to follow the convention, I'd stick to the queryable stuff.
-
I almost always take it out of clients when I see them using it, because it's in cases where it was never designed for.
-
I've seen it work quite well, and in large-scale, years-long projects, but ONLY because we used it for its intended use case, and not everywhere in the app we saw setters.
-
As others have said, when there’s more MapFrom than auto [DO NOT USE IT]. It should be like, 95% or more stock behavior. Maybe much higher. It can do a lot but you shouldn’t make it do a lot. It should be dumb.
Excerpts from StackOverflow of his replies to a “Friends Don’t Let Friends Use Automapper” blog post:
-
AutoMapper was never, ever intended to map back into a behavioral model. AutoMapper is intended to build DTOs, not map back in
-
Mapping to complex models. I only use AutoMapper to flatten/project, never back to behavioral models. I'm very up front about this and discourage this use whenever I see it.