Projection does not call call Map()

[AllanMichaelsen]

When mapping an EF Entity with projection, the Map() method is not called.

    public static Expression<Func<global::UnitEntity, UnitDto>> Projection =>
        source => new UnitDto
        {
            Id = source.Id,
            ...
        };

The constructors do call the Map()

    public UnitDto(global::UnitEntity source, int __depth, System.Collections.Generic.HashSet<object>? __processed)
    {
        this.Id = source.Id;
        ...
        global::UnitDtoMapConfig.Map(source, this);
    }

Would it not be more maintainable if the Projection() method called the Constructor?

    public static Expression<Func<global::UnitEntity, UnitDto>> Projection =>
        source => new UnitDto(source, 0, new System.Collections.Generic.HashSet<object>(System.Collections.Generic.ReferenceEqualityComparer.Instance));

That way there is only one set of generated code, and the linearity of the projection (imho) seems more direct. Not sure how this would go with the projection and pulling all the needed includes :-)

[Tim-Maes]

Hi @AllanMichaelsen

I think this issue addresses a real gap in my docs and user experience

Projection is an Expression<Func<TSource, TTarget>> that EF Core translates directly to SQL. For that translation to work, Facet must use object initializer syntax (new UnitDto { Id = source.Id, ... }). EF Core can translate MemberInitExpression, but cannot translate the constructor calls, so delegating to the constructor inside a Projection expression would silently break EF Core query execution (like it would force client-side evaluation or throw at runtime).

Currently, I can see 2 potential improvements:

1 - a Roslyn diagnostic warning, emit a compiler warning when Configuration = typeof(...) and GenerateProjection = true are combined, so users know at compile time that Map() won't run during projections.

2 - ProjectionInMemory property, a second generated property that delegates to the constructor (likeyou suggested). This wouldn't be EF Core safe, but would be correct for in-memory LINQ (.Select(UnitDto.ProjectionInMemory) on a List<T>)

Would either of these 2 help your case? What do you think?

[AllanMichaelsen]

As I see it none of those solutions would make this ".Include() free".

Like I said in one of my previous posts here, I come from a AutoMapper setup where I use the mapping in the projection. Now I know there are some language limitations to that, but it does not need .Include for related entities.

Is there some way to implement it similar to that so there might be limitations to language, but no need for .Include?

[Tim-Maes]

After doing some research, I believe the best way to achieve this is some new interface where users declare their custom mappings as expression trees rather than imperative code. The generator detects when the config class implements this interface and switches from a static expression literal to a lazy expression built at runtimethat inlines the user's custom bindings.

For example something like:

 public interface IFacetProjectionMapConfiguration<TSource, TTarget>
{
    static abstract void ConfigureProjection(IFacetProjectionBuilder<TSource, TTarget> builder);
}

public interface IFacetProjectionBuilder<TSource, TTarget>
{
    IFacetProjectionBuilder<TSource, TTarget> Map<TValue>(
        Expression<Func<TTarget, TValue>> targetMember,
        Expression<Func<TSource, TValue>> valueExpression);
}

And usage:

public class UnitDtoMapConfig
    : IFacetMapConfiguration<UnitEntity, UnitDto>,
      IFacetProjectionMapConfiguration<UnitEntity, UnitDto>
{
    // current
    public static void Map(UnitEntity source, UnitDto target)
    {
        //mapping that runs in constructors
    }

    // new
    public static void ConfigureProjection(IFacetProjectionBuilder<UnitEntity, UnitDto> builder)
    {
         // expression based :
        builder.Map(d => d.FullName, s => s.FirstName + " " + s.LastName);
    }
  }

Map() For things EF can't do, ConfigureProjection for things EF can translate. I think the Include() would not be affected.

This would require a lot of work in the projection generator code but I think this might solve the problem.

[AllanMichaelsen]

That does indeed sound like it would solve the mapping in a once over config. Looking forward to it when you've had time to look at it 😇

[Tim-Maes]

I think I nailed it down for a v1 version of this. Going to ship it in an alpha preview package for you to test it out!

[Tim-Maes]

v6.1.0-alpha should be available soon. Let me know if this works for you!

[AllanMichaelsen]

Question: To avoid doubling the code if I need Constructor and projection mapping, is it possible to just configure the projection mapping and let the Constructor mapping use that?

That way it is optional to even use the projection style builder for Constructor mapping if one wants to "future proof" the mapping config.

[Tim-Maes]

Latest preview package should contain this improvement. Thanks