ExpressionTree rewrite - параметр 'x' находится за пределами области видимости. - PullRequest
Новая
       36

ExpressionTree rewrite - параметр 'x' находится за пределами области видимости.

2 голосов
/ 07 сентября 2011

Если я сделаю какие-либо ошибки / опечатки в следующем коде, пожалуйста, не раздражайтесь, просто оставьте комментарий здесь, и я немедленно исправлю - спасибо

Цель

Переназначение Expression<TDelegate> с одного EntityA на EntityB.

Я подозреваю, что такого рода вещи были сделаны раньше, но я не нашел особо полезных ссылок, поэтому чувствуюВы можете указывать мне правильное направление.

Пока у меня есть выбор классов, которые позволяют создавать сопоставления между членами Entity в двух заданных классах.Например, API поверхности может иметь следующую сигнатуру: 

public void AddMemberBinding<TEntityA, TEntityB, TMember>(Func<TEntityA, TMember> entityAMemberSelector, Func<TEntityB, TMember> entityBMemberSelector)
{
    // does some magic, eventually storing the necessary MemberInfo details required to
    // "remap" MemberExpressions (MemberAccess) from TEntityA to TEntityB
}

Учитывая следующие классы ... 

public class EntityA
{
    public long Id { get; set; }
    public string Name { get; set ;}
}
public class EntityB
{
    public long MyId { get; set; }
    public string MyName { get; set; }
}

Вы сможете создавать привязки с чем-то вдоль линийиз ... 

public static void AddBindings()
{
    AddMemberBinding((EntityA n) => n.Id, (EntityB n) => n.MyId);
    AddMemberBinding((EntityA n) => n.Name, (EntityB n) => n.MyName);
}

В моем случае у меня есть Assembly1, который знает, что такое EntityA, но не знает EntityB.У меня есть Assembly2, который знает, что такое EntityA и EntityB, и виден для Assembly1.Assembly2 предоставляет метод для Assembly1, который может выглядеть следующим образом: 

public static IEnumerable<EntityA> GetData<TResult>(Expression<Func<EntityA, bool>> criteria, Expression<Func<EntityA, TResult>> selector)
{
    // EntityB's are stored in a database, I could do one of two things here...
    // 1) Return all EntitieB's and then apply criteria and selector through the IEnumerable extensions
    //    this would be sub-optimal - particularly if there are millions of EntityB's!
    // 2) "Transmute" (for lack of a better word) the expressions provided, using the keymappings
    //    specified earlier, to derive expressions that can be passed through to the QueryableProvider
    // ... as you might have guessed, I opted for #2
}

Я использую производную версию ExpressionTree Visitor со следующими переопределенными методами: 

protected override Expression VisitLambda(LambdaExpression lambda)
{
    Type targetParameterType = lambda.Parameters[0].Type;
    Type targetExpressionType = lambda.Type;
    If (lambda.Parameters.Count = 1 && lambda.Parameters(0).Type == EntityA)
    {
        targetParameterType = EntityB;
        // the `GetResultType` method called gets the TResult type from Func<T, TResult>
        Type targetExpressionResultType = GetResultType(lambda);
        targetExpressionType = gettype(Func<EntityB, targetExpressionResultType>) 
    }
    // this is probably wrong, but maintains the current (last) parameter instance
    // I started doing this after reading about a similar issue to mine found:
    // /321963/expression-or-parametr-item-nahoditsya-vne-oblasti-vidimosti
    this.CurrentLambdaParameters = lambda.Parameters.Select(x => Expression.Parameter(targetParameterType, x.Name));
    Expression body = this.Visit(lambda.Body);
    If (body != lambda.Body)
    {
        return Expression.Lambda(targetExpressionType, body, this.CurrentLambdaParameters);
    }
    return lambda;
}

protected override Expression VisitMemberAccess(MemberExpression m)
{
    // at this point I go off and look at key mappings, fetch the mapping required, etc
    // the entity I retrieve has a `TargetMemberInfo` property which is a `MemberInfo` for the
    // member on the target entity - speaks for itself I guess...
    return Expression.MakeMemberAccess(this.CurrentParameters.Single(), myMappingClassThing.TargetMemberInfo);
}

Проблема

После всего сказанного и сделанного, когда я запускаю код с тестовым примером, я получаю ошибку в заголовке ... Я вижу, что это параметрпроблема из описания, но прочитав о похожая проблема Я надеялся, что учел проблему в методе VisitMemberAccess, используя параметр, который я создал при изменении корневого лямбда-выражения - тот же экземпляр ParameterExpressionя думаю, что исправил проблему со связанными вопросами?

Кажется, я не очень хорошо понял эту часть процесса.Вопрос в том, где я ошибся !?Что мне нужно делать с этими ParameterExpressions, чтобы они были «в поле зрения»?

Заранее благодарю за ответы, и если вы прочитали это далеко, слава вам !!

1 Ответ

1 голос
/ 07 сентября 2011

Просматривая удивительно похожий вопрос Джона и рефакторинг, чтобы включить пару его приемов, которые я предпочел для своей собственной реализации, я наткнулся на ответ.Я заметил, что VisitParameter никогда не вызывался, причина в том, что мое переопределение VisitMemberAccess прекратило рекурсию через дерево выражений.

Это должно было выглядеть (используя другую перегрузку): 

protected override Expression VisitMemberAccess(MemberExpression m) 
{ 
    return Expression.MakeMemberAccess(Visit(m.Expression), myMappingClassThing.TargetMemberInfo); 
}

Объедините это с гарантией того, что вы не создадите несколько экземпляров одного и того же параметра, и все будет правильно совмещено.

Еще раз спасибо Джону!=)

...