Why only one instance of MapperConfiguration per app domain?

[robert-stokes-orion]

I am trying to understand why it is recommended to only use 1 MapperConfiguration per app domain. Is it a style/best practice thing or are their performance consequences to having multiple?

AutoMapper is not heavily adopted in the code base I am working in. Currently there are 3 instances of MapperConfiguration and I am considering adding a 4th. If there is no performance hit I may wait until I have more time to add it to our StartUp class.

Thoughts?

[jbogard]

Because mappers are created from mapper configurations, and typically those mappers are injected via DI. There's no built-in mechanism to get a specific mapper for a specific configuration, so you'd have to use something like named instances in DI.

Not required but you'd have to come up with your own way of managing configurations/mappers yourself otherwise.

[robert-stokes-orion]

OK that makes sense. Currently I am just accepting AutoMapper as a dependency and not injecting it or adding it to our IoC container.
It is also possible I am not using AutoMapper to its full potential; I am only using it for mapping large DTO's where most of the prop names are the same but where it is messy/impractical to map them in code.

[lbargaoanu]

But, no matter how many configurations you have, for performance reasons, they all should be created once and reused.

[robert-stokes-orion]

Sounds good. If there is a performance hit I will convert my code to use a single instance.