Mapping list to another list dynamically

Question

I had an idea for a piece of software using .NET C# as technology.

Basically, in my idea Im thinking of using reflection to do the mapping between a class to another class using interactivity with a user.

About the interactivity right now Im just using console writeline and readline, but in future it can also be something different like signalR.

The final goal is that after the mapping of properties is done, we can run a a conversion between the contents of a list (an input list) and create an output list.

I know that there are libraries that help with mapping like "AutoMapper" but I think they work well if the properties are the same name and it doesn't work at run time.

So what Im trying to do is more generic.

What I have right now in terms of classes is:

public class ObjectAssignementService<TI, TO>

that is responsible to fill some properties that will contain metadata about the 2 classes and how they map between them and if there is a specific conversion that needs to happen like a decimal converted into a string.

Then another class that runs after

public class ConvertService<TI, TO>

This class will be injected with the previous class, and it will do the conversion of the input list to created the output list.

My explanation may need improvement, but this is still a POC. And Im interested in getting feedback if this seems like a good idea? Anyone with experience doing similar pieces of work? Thanks.

Console app POC:

Answer 1

I suggest you (re)visit the Automapper docs and really check to see if what you need isn't already in there, or if it will get you most of the way.

I know that there are libraries that help with mapping like "AutoMapper" but I think they work well if the properties are the same name ...

Automapper automatically knows how to link two properties if and when the names are the same, but Automapper is just as capable of linking two properties with different names. It just can't guess that for you, so you have to tell it how to link them.

cfg.CreateMap<Foo,Bar>()
    .ForMember(
        bar => bar.BarProp, 
        opt => opt.MapFrom(foo => foo.FooProp)
    );

The above example links FooProp to BarProp and in this case it assumed that they are compatible types. If they are different types, e.g. int to string, you can adapt the code, e.g.:

        opt => opt.MapFrom(foo => foo.FooProp.ToString())

Automapper also sports both custom type converters and custom value resolvers.
The former allows you to define the conversion based on the object you're converting, the latter does it based on the type of the individual properties being mapped.

... and it doesn't work at run time.

The conversion logic (i.e. the foo => foo.FooProp in the above example or any of the code you put into a converter/resolver) is executed at runtime. Anything you put in there will be executed at runtime.

If you want to write this logic in a way that it blocks until user confirmation has been provided, that's possible. It's not performant, but if you need user involvement, then performance is not your key focus anyway.

---

The screenshot you provided seems to be doing a pre-emptive check if a mapping would work, before you have an actual object with values that you wish to convert. Configuration validation is also something Automapper sports:

var configuration = new MapperConfiguration(cfg =>
       cfg.CreateMap<Source, Destination>()
    );

configuration.AssertConfigurationIsValid();

The CreateMap line can of course be replaced by whatever your mapper configuration is. You could perform this test for each mapping separately, or you could load up everything and see if everything works. That's up to you to decide what makes sense for you.

Note that Automapper only tests its configuration based on the properties in the target. If your source has 10 properties, and your target has 2 properties, it's only going to see if it knows how to map to those two target properties. It won't care if there are any properties in the source that are not used in the mapping.

---

I can't tell you what the exact solution here is since you have not worked it out yourself (or have not explained it in the question); but I see no reason to discount Automapper as a tool to help you define value mapping logic.