Non-static version of Mapper

Things to do:

• Introduce non-static API
• Obsolete existing static API
• Provide bridge for LINQ #1038
• Read-only configuration #1039

I want to move to a non-static version of AutoMapper, that would get rid of so many headaches on my part of threading and junk. I’m thinking of something like:

var mapper = new Mapper(cfg => cfg.CreateMap<Source, Dest>());

var dest = mapper.Map<Source, Dest>(new Source());

I’d have overloads for the ctor:

public Mapper(Action<IConfiguration> configure);

public Mapper(IConfigurationProvider configuration);

And the configuration provider, if you wanted to initialize that by itself, could have a ctor too:

public class Configuration(Action<IConfigurationProvider> configure) {
   configure(this);
}

Technically configuration is still mutable after Seal(), since you can still go into TypeMaps and do whatever, grab the instance of the configuration and so on.

Motivation

The static has been haunting me for years. Threading issues, order-of-operations, I can’t fix that until I get rid of the statics. The changes in inheritance in 4.x have opened enough issues that I want to be deliberate about this move.

Upgrade path

If you’re using Mapper.Initialize, it’s a matter of replacing the outer path with the real thing. I want to use the Mapper class and a Configuration class. I would obsolete all the static methods, obsolete the MappingEngine class and make the Mapper class inherit from it for 4.2. Then in 5.0, remove all the static.

Users, instead of calling Mapper.Map, would use a mapper instance directly, which they can make static all they like. Or configure in a container, whatever.

Static compromise

Another option is to keep Mapper.Initialize and Mapper.Map and nothing else. Still include static field for the mapper and the configuration instances. I would still remove the static keyword from Mapper and move the MappingEngine pieces inside of Mapper, with the clear signal that “you might want to use the instance methods”.

I want to move to a class called “Mapper” and in C# a static method hides an instance method of the same name. It’s basically static or nothing. I could do something like Mapper.Engine.Map but that seems hokey.

@TylerCarlson1 @lbargaoanu thoughts?

[long2know]

I have no qualms with the new approach, but some things do not work the same and was wondering if you could provide some guidance.

One aspect that I am unsure as I migrate code from 3.x is mapping custom collections. In particular, I have a PaginatedList<T> which inherits from List<T>, but includes paging properties like page number, sortby, etc.

The old way to deal with this was to have an extension method that would map the custom members and then use AfterMap to map the enumerable elements.

It looked something like this:

Mapper.CreateMap<Type1, Type2>().IncludePagedResultMapping();

public static IMappingExpression<TSrc, TDest> IncludePagedResultMapping<TSrc, TDest>(this IMappingExpression<TSrc, TDest> expression)
{
  Mapper.CreateMap<PaginatedList<TSrc>, PaginatedList<TDest>>()
.ForMember(dest => dest.PageNumber, opt => opt.MapFrom(src => src.PageNumber))
.ForMember(dest => dest.SortBy, opt => opt.MapFrom(src => src.SortBy))
.AfterMap((s, d) => Mapper.Map<List<TSrc>, List<TDest>>(s, d));

return expression;
}

However, changing this to create a Mapper in the AfterMap (.AfterMap(s,d) => _config.CreateMapper().Map(....)) causes a stackoverflow.

Is there a preferred, working approach to these types of scenarios in 4.x? I looked at the wiki regarding Open Generics, and that didn’t seem to be the right path.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.