Mapper seems to ignore a configured data-source

[bslbckr]

Hi,

I have a, at first sight, pretty easy example:

namespace Source {
  public interface IData {
	  string Id {get; set;}
  }
  public interface IEmpty : IData {}
	public class Data : IEmpty {
		public string Id {get; set; }
	}
	
	public class Container {
		private readonly IEmpty _empty;
		public Container() {
			_empty = new Data{Id = "12345"};
		}
		public string Name {get; set;}
		public IEmpty Empty {get { return _empty;}}
	}
}

namespace Target {
	public class Data {
		public string Id {get;set;}
		public string Value {get;set;}
	}
	
	public class Cont {
		public Data Info {get; set;}
		public string Name {get; set;}
	}
}

the mapping configuration looks as follows:

Mapper.WhenMapping.From<Source.Container>().To<Target.Cont>().Map(src => src.Source.Empty).To( tgt => tgt.Info);

the corresponding mapping plan looks like:

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
// Map Container -> Cont
// Rule Set: CreateNew
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

cToCData =>
{
    try
    {
        var cont = new Cont();
        cont.Info = cont.Info;
        cont.Name = cToCData.Source.Name;

        return cont;
    }
    catch (Exception ex)
    {
        throw MappingException.For(
            "CreateNew",
            "Container",
            "Cont",
            ex);
    }
}

My expectation is that the mapper maps Source.Container.Empty to Target.Cont.Info

Further, I only build this small example as I had the impression, that inheritance structure in the Source namespace confuses the mapper, such that it doesn't recognize the IEmpty actually has a property named Id.

As usual I have a corresponding fiddle: https://dotnetfiddle.net/6AupKd

[SteveWilkes]

Thanks!

There was a bug here with the mapper not checking for a source interface member's implemented interface members (there's a mouthful) - it's fixed in the latest 1.5 release code, release to follow.

If Source.Data - but not Source.IEmpty or Source.IData - had a Value member, would you expect Target.Value to be populated? The mapper doesn't currently check an interface member's implementation type to look for data sources, but it could...

Thanks again :)

[SteveWilkes]

This is fixed as of v1.5 preview 2, which is now on NuGet.

The mapper still uses the declared type of an interface source member instead of checking the implementation type - I'd be interested to hear your thoughts on that!

[bslbckr]

This is fixed as of v1.5 preview 2, which is now on NuGet.

That's great news. We will give it a try the next days.

The mapper still uses the declared type of an interface source member instead of checking the implementation type - I'd be interested to hear your thoughts on that!

I really struggle giving a concrete answer to this question. The mapper's overall experience is strongly typed what gives the benefit of cached and compiled execution plans and assumably speed up the overall mapping performance. So this is a strong point towards keeping it, as it is. However, I also could imagine situations where the expectation of users could be that the implementation type should be considered. I fail to weigh both points against each other and don't want to give the lame and obvious answer: make it configurable :)

However, what I found out being quite problematic at the moment is a slightly different situation: Assuming you have the following source structure

interface MyInterface {
  int Id {get; set; }
}
class ImplementationA : MyInterface {
  public int Id {get; set: }
  public string FancyMember {get; set;}
}
class ImplementationB : MyInterface {
  public int Id {get; set: }
  public bool IsFancy { get; set;}
}

class Container {
  public MyInterface Foo {get; set;}
}

and you want to map it to a pretty simple target structure:

enum Implementation {
   A,
   B
}

class Interface {
   public Implementation {get;set;}
   publi int Id { get; set;}
}

class Container {
  public Interface Foo {get;set;}
}

There is no way to specify different mapping configurations for the two possible implementation types. It would be great, if there were a generic conditional, i.e. If<ImplementationA>().Map(Implementation.A).To(tgt => tgt.Impl). the existing Map<ImplemenationA> could not be re-used for this purpose. Probably this is a completely new enhancement.

the usual link: https://dotnetfiddle.net/z3X3de

[SteveWilkes]

Interesting! I might make implementation-type mapping configurable...

You can configure the second example like this:

    Mapper.WhenMapping
        .To<Target.Interface>()
	.If(ctx => ctx.Source.GetType() == typeof(Source.ImplementationA))
	.Map(Target.Implementation.A).To(tgt => tgt.Impl)
	.But
        .If(ctx => ctx.Source.GetType() == typeof(Source.ImplementationB))		 
        .Map(Target.Implementation.B).To(tgt => tgt.Impl);

...but it would be smoother to have the mapper perform a map-time check on the source object. It also currently throws an exception if you use an is or as test in an .If() condition, but I should probably allow that if it's mapping from an interface:

    Mapper.WhenMapping
        .From<Source.MyInterface>().To<Target.Interface>()
	.If(ctx => ctx.Source is Source.ImplementationA)
	.Map(Target.Implementation.A).To(tgt => tgt.Impl)
	.But
        .If(ctx => ctx.Source is Source.ImplementationB)
        .Map(Target.Implementation.B).To(tgt => tgt.Impl);

Thanks again for the feedback!

[bslbckr]

It also currently throws an exception if you use an is or as test in an .If() condition,

we already noted that ;-)
My idea with the special form of the .If() condition was to not confuse users if the mapper sometimes allows it and sometimes it throws an exception.

[SteveWilkes]

I've updated the latest 1.5 release code to allow type tests when the source type is an interface, but I want to encourage using .From<TSource>() where possible (hence the exception) as it allows the mapper to create better mapping functions.

We could have .IfSourceIs<TSource>(), but I'm not sure about adding to the configuration API for what feels like a fairly edge case...