Support ExpressionType.Call in MappingSetterVisitor

[rmusco]

Nowadays only Constants are accepted in FlatFileDefinition field mapper. This is enough when we know exactly the format of the source file, but I have an use case where the user needs to specify the in which columns data needs to be extracted from, making it flexible to support different file formats.
E.g.:
File 1 - FirstName, LastName, DOB, Nationality
File 2 - Nationality, MobileNumber, FirstName, LastName, DOB

By supporting ExpressionType.Call in MappingSetterVisitor, it's possible to have a generic reader method IFieldMapper.ToColumn can receive something like "dictionary[nameof(Class.FirstName)]" and the dictionary can be defined by the users in a previous configuration or when the file is uploaded into the system.

public class MappingSetterVisitor : ExpressionVisitor
    {
        public MappingSetterDefinition MappingSetter = null;
        protected override Expression VisitMethodCall(MethodCallExpression node)
        {
            DummyFieldMapper dummyFieldMapper = new DummyFieldMapper();
            var methodInfo = node.Method;

            switch (node.NodeType)
            {
                case ExpressionType.Constant:
                case ExpressionType.Call:
                    methodInfo.Invoke(dummyFieldMapper, node.Arguments.Select(i => GetValue(i)).ToArray());
                    break;
                default:
                    throw new NotSupportedException($"Expression type {node.NodeType} not supported.");
            }

            this.MappingSetter = dummyFieldMapper.MappingSetter;
            return null;
        }

        private object GetValue(Expression member)
        {
            if (member is ConstantExpression)
                return ((ConstantExpression)member).Value;

            var objectMember = Expression.Convert(member, typeof(object));
            var getterLambda = Expression.Lambda<Func<object>>(objectMember);
            return getterLambda.Compile()();
        }
    }

[paillave]

Actually in the context of the mapper, the expression is meant to be very simple (represent a simple function call on the parameter of the lambda expression). The reason for this is that this mapping is meant to work both ways: reading and writting. This is why the expression is not compiled to be exectued (otherwise a simple Func would have been better and more flexible like you suggest). The expression is meant to be analysed to understand how the mapping works. Then, the right line parser with the correct setup is build in order to read AND write in the most efficient way.

This mechanism is reused here or there in ETL.NET for some other addons as it is a strongly typed and efficient way to describle an input/output mapping.

I will consider your purposal, but its complex reading implemetation would not permit the mapper to work for file writting.

If you feel like it, you can make a pull request, but bear in mind that writting a file must still work, at least if expressions remain as simple as it is required now.

[rmusco]

Fair enough... I was testing Read-only operations. Let me do further tests to write and see how it goes.
Thanks for the reply!