Allow mapper configurations on expression & queryable projection mappings

[mhartmair-cubido]

Is your feature request related to a problem? Please describe.
Queryable projection is verbose. In almost all other mappers, these are generated for you by convention.

Describe the solution you'd like
Provide a Mapper configuration (opt-in or opt-out) for generating IQueryable-projections and/or expressions automatically for each defined mapping method without having to define the method definitions. The generated projection should have the same visibility modifier as the mapping definition. The generated names are ProjectTo{TDestination.Name} in order to have a unique intuitive name. (Optionally, the prefix ProjectTo and suffix `` could be configured in the defaults). The generated name can be configured via new attributes MappingProjection(string methodName) and `MappingExpression(string methodName)`.

[Mapper(GenerateQueryable = true, GenerateExpression = true)]
public static partial class PersonDtoMapper
{
    [MappingProjection("MyCustomName")]
    public static partial PersonDetailDto MapToPersonDetailDto(PersonDbo src);
    public static partial PersonViewDto MapToPersonViewDto(PersonDbo src);

    // Expect this projection to be generated because of GenerateQueryable = true
    // public static IQueryable<PersonDetailDto> MyCustomName(this IQueryable<PersonDbo> src) { ... }
    // public static IQueryable<PersonViewDto> ProjectToPersonViewDto(this IQueryable<PersonDbo> src) { ... }

    // Expect this expression to be generated because of GenerateExpression = true
    // public static Expression<Func<PersonDbo, PersonDetailDto>> ProjectToPersonDetailDto() { ... }
    // public static Expression<Func<PersonDbo, PersonViewDto>> ProjectToPersonViewDto() { ... }
}

Describe alternatives you've considered

• Define all projection method definitions by hand.
• Allow all attributes that work on mapping methods to work on projection method definitions to avoid the unused mapping method definition without projection that is used solely for mapping configuration.

Additional context

[latonz]

Today the explicit projection / expression method declaration is intentional. One important reason is that the entire public mapper API stays clearly defined by the user: which methods exist, what they are called, and what visibility they have.

Automatically generating sibling IQueryable projections and expression factories for every object mapping would expand that public API implicitly and add quite a bit of naming, discoverability, and configuration complexity. It also gets awkward once multiple mapping variants exist for the same source / target pair.

In the scenarios I usually see, the exact mapping is also not shared 1:1 between queryable projection and regular object mapping. So before considering a feature like this, I would first want to understand the concrete usage context where both should always be generated together.

There is also a performance aspect on the generator side. Mapperly uses RegisterImplementationSourceOutput here instead of RegisterSourceOutput, which wouldn't work anymore with generated APIs.

[mhartmair-cubido]

I would first want to understand the concrete usage context where both should always be generated together.

On the contrary, we only need the projection for EF Core queries, but the plain mapping method definition is required for mapping configuration.

What do you think about allowing the mapping configuration directly on the projection method definition instead? One could still use [IncludeMappingConfiguration] when both are needed (maybe a MapperDefaults-property for backwards compatibility would be nice).

Before:

[Mapper]
public static partial class PersonDtoMapper
{
    [MapProperty(...)]
    private static partial PersonDto MapToPersonDto(Person src);
    public static partial Expression<Func<Person, PersonDto>> MapToPersonDto();
}

After:

[Mapper]
public static partial class PersonDtoMapper
{
    [MapProperty(...)]
    public static partial Expression<Func<Person, PersonDto>> MapToPersonDto() { ... }
}

[latonz]

Yep I think we could allow that. We thought on this in the past but decided against it since it feels unnatural applying MapProperty on expressions / queryables. But thinking on this again I think it makes the configuration easier.

When implementing this, remove RMG065.
Feel free to contribute 😊