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

2

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

Цель

Переформатируйте Expression<TDelegate> с одного EntityA на a 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 are stored in a database, I could do one of two things here...
    // 1) Return all EntitieB 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:
    // /questions/634577/expressionor-the-parameter-item-is-not-in-scope
    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, используя параметр, который я создал при изменении выражения lambda корня - тот же самый экземпляр ParameterExpression устранил проблему связанных вопросов Я думаю?

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

Заранее благодарим за ваши ответы, и если вы прочтете это далеко, то вам будет приятно.

  • 0
    Это напоминает мне о похожем вопросе, который у меня был в прошлом. Посмотри, поможет ли тебе этот. Примечание: конечный результат был гораздо более сложным, чтобы автоматически учитывать несколько случаев, но основная идея та же.
  • 0
    Это выглядит идеально, Джон. Я дам вам знать, как я в ближайшее время. Хотелось бы, чтобы ваш вопрос всплыл в поиске, когда я начал свой !!
Показать ещё 2 комментария
Теги:
lambda
expression-trees
.net-3.5

1 ответ

1
Лучший ответ

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

Он должен был выглядеть (с использованием другой перегрузки):

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

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню