Если я сделаю ошибки/ошибки в следующем коде, пожалуйста, не обходите меня, просто напишите здесь, и я исправлю сразу - спасибо
Переформатируйте 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 устранил проблему связанных вопросов Я думаю?
Кажется, я не очень хорошо понял эту часть процесса. Вопрос в том, где я ошибся!? Что мне нужно делать с этими параметрами, чтобы они были "в области видимости"?
Заранее благодарим за ваши ответы, и если вы прочтете это далеко, то вам будет приятно.
В то время как я смотрел Джон удивительно похожий вопрос и рефакторинг, чтобы включить пару своих практик, я предпочел свою собственную реализацию, я наткнулся на ответ. Я заметил, что VisitParameter
никогда не вызывался, причина в том, что мое переопределение VisitMemberAccess
прекратило рекурсию через дерево выражений.
Он должен был выглядеть (с использованием другой перегрузки):
protected override Expression VisitMemberAccess(MemberExpression m)
{
return Expression.MakeMemberAccess(Visit(m.Expression), myMappingClassThing.TargetMemberInfo);
}
Объедините это с гарантией того, что вы не создадите несколько экземпляров одного и того же параметра, и все слоты вместе красиво.
Еще раз спасибо Джону! =)