Use .NET 8 Interceptors to allow Mapperly to be added to existing methods?

[TallBaldGeek]

Hi,

I've been reading a bit about a new feature coming in .NET 8 called "Interceptors" and it seems to me like these could be leveraged to extend Mapperly in a different direction. (I found this post by Khalid Abuhakmeh from the JetBrains team to also be helpful in understanding Interceptors)

Currently in our application, we use reflection to map from DTOs used by our front end to DTOs used by our backend. This is done with a generic extension method like this:

public static TBackend MapFrom<TBackend , TFrontEnd>(this TBackend target, TFrontEnd source)
{
    //reflection used here
}

The benefit to this approach is that it can be applied to any type, but the drawback is that it's using reflection. To use Mapperly in its current form, we would need to implement partial classes/methods for each unique combination of frontend and backend DTO.

Would it be possible to use .NET 8 Interceptors to allow us to decorate our existing methods such that Mapperly would then generate the needed mapping across our application for any combination of DTOs passed to the method? Something like

[Mapper(UseDeepCloning = true, AllowNullPropertyAssignment = false)]
public static TBackend MapFrom<TBackend , TFrontEnd>(this TBackend target, TFrontEnd source)
{
    //Mapperly would intercept calls to this method and replace with generated mapping
}

Thanks!

[TimothyMakkison]

Hey, thanks for the idea. I've been pretty excited by interceptors as well.

I'm not sure if this idea would be approved. How would configuration work?

Interestingly, what you suggest is already possible with current source generators. By scanning for usages of MapFrom it would be possible to create a method overload with the matching parameters. As C# tries to use the most specific method it would use the generated method over a different one. No interception needed! Although the proposed api to find matching methods would speed this up.

Iirc someone made a project which does this I'll try to find it later

[TallBaldGeek]

How would configuration work?

I assume you mean how would different mappings be handled for different DTOs?

My thought was that you'd define one mapping strategy in the attribute that you apply at the method level and that would apply to all calls to that method. Meaning, there wouldn't be a way to configure the mappings for SourceDtoA <-> TargetDtoA different than SourceDtoB <-> TargetDtoB. It would probably have to be one-size-fits-all? Like "give me all the matching name properties, deep cloned, ignore nulls, case sensitive" rules would apply to all calls to MapFrom that were subsequently generated.

Iirc someone made a project which does this I'll try to find it later

If you do run across something besides Mapperly that already handles things the way I describe above, I'd love to hear it. Thanks!

[TimothyMakkison]

Found the project! Its called NextGenMapper and uses var destination = source.Map<Destination>(); style syntax. He has a section on how this works without interceptors here.
`

My thought was that you'd define one mapping strategy in the attribute that you apply at the method level and that would apply to all calls to that method. Meaning, there wouldn't be a way to configure the mappings for SourceDtoA <-> TargetDtoA different than SourceDtoB <-> TargetDtoB. It would probably have to be one-size-fits-all? Like "give me all the matching name properties, deep cloned, ignore nulls, case sensitive" rules would apply to all calls to MapFrom that were subsequently generated.

I've played around with this a little, supporting configuration while being reusable is hard.

Some of my ideas:

// fluent configuration, breaks/hard to do if someone breaks up the calls
// hard to share, would have to make a class with these calls inside each method
source.Adapt<MyDto>()
           .Map(src=>src.Dog, trg => trg.Cat)
           .WithDeepClone();

// global scope, call inside an unused method
Mapperly.Map<MyClass, MyClassDto>()
                .Map(src=>src.Dog, trg => trg.Cat)
                .WithDeepClone();
var target = source.Map<MyClassDto>();

// could have configuration context system i.e.
Mapperly.Context("mapper1")
                .Map<MyClass, MyClassDto>()
                .Map(src=>src.Dog, trg => trg.Cat)
                .WithDeepClone();
var target = source.Map<MyClassDto>(context: "mapper1");

[latonz]

A fluent API could be made possible with the new interceptors.
However, the problem of OP consists outlined here #646 (comment) consists. Especially if the map method is called from other assemblies/projects/solutions.

[TimothyMakkison]

A fluent API could be made possible with the new interceptors.

True, I think the other wouldn't need it. It might be possible to backport it by making each configuration method "useless" but record its location, passing this to a static method. This can be used to match a fluent call to its generated static method. Extremely hacky.

However, the problem of OP consists outlined here #646 (comment) consists. Especially if the map method is called from other assemblies/projects/solutions.

Would this be prevented by making the extensions mapper internal? I guess a method could be exposed by doing:

public static class Mappers
{
    public static MyClassDto Map(this MyClass source) => source.Map<MyClassDto>();
}

An attempt could be made to find all calls to the mapping method at compile time and generate mappings for the appropriate types. However, this won't work reliably and would probably significantly slow down the compilation process.

True, I'm not sure how much time this would take. Looking at Mediator and NextGenMapper they use the OnVisitInvocationNode building a configuration tree. Unfortunately, breaking the calls up can break this.

[TallBaldGeek]

Found the project! Its called NextGenMapper and uses var destination = source.Map<Destination>(); style syntax. He has a section on how this works without interceptors here. `

Got it, thanks! That looks promising, although one thing it's lacking (for my purposes) is support for using an existing target DTO, like Mapperly supports. Maybe that's a feature the author would be able/willing to add.

[latonz]

The idea of the new .NET interceptors is to generate the implementation of methods dynamically at compile time by a source generator.

The problem here is that at compile time it is not known what types the arguments will have at runtime. However, Mapperly is designed to generate all mappings for all supported types at compile time, which cannot work here.
An attempt could be made to find all calls to the mapping method at compile time and generate mappings for the appropriate types. However, this won't work reliably and would probably significantly slow down the compilation process.
The same applies to other source generators, eg. for the System.Text.Json source generator, all types that can be serialized must be specified with JsonSerializable.

[TallBaldGeek]

Thanks for the details. I am not too familiar with source generators, I haven't had experience working with them.

... An attempt could be made to find all calls to the mapping method at compile time and generate mappings for the appropriate types. However, this won't work reliably and would probably significantly slow down the compilation process.

That was kind of what I was envisioning, at least at a high level. If we assume an implementation using attributes to decorate a method as in my first post:

[Mapper(UseDeepCloning = true, AllowNullPropertyAssignment = false)]
public static TBackend MapFrom<TBackend , TFrontEnd>(this TBackend target, TFrontEnd source)
{
    //reflection used here
}

I was picturing something like this happening:

1. Compile happens
2. Mapperly generators inspect the call tree for all references to MapFrom and build a list of TBackend & TFrontEnd combinations
3. The generators then build replacements for MapFrom that use generated Mapperly mappings
4. If a caller somehow snuck through the cracks, the default reflection based implementation could still be used

The above is probably full of ignorance and bad assumptions because I've not worked with source generators.

[latonz]

The problem is the call tree inspection at compile time. Mapperly can never be sure to catch most/all possible types (eg. a public method can be invoked from any referenced assembly, which is not scannable by Mapperly). Also Mapperly will never fall back to a reflection based approach. One of the core advantages of Mapperly is to be reflection free and therefore be trimming and AoT save.

[TallBaldGeek]

Thanks for the clarification and explanation, and for tolerating my ignorance of how Mapperly works. I appreciate your time.