Есть ли особая причина, по которой расширитель LinqKit не может получать выражения из полей?

Я использую библиотеку LinqKit, которая позволяет комбинировать выражения на лету.

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

Рассмотрим следующий фрагмент кода:

private static readonly Expression<Func<Message, int, MessageView>> _selectMessageViewExpr =
    ( Message msg, int requestingUserId ) =>
        new MessageView
        {
            MessageID = msg.ID,
            RequestingUserID = requestingUserId,
            Body = ( msg.RootMessage == null ) ? msg.Body : msg.RootMessage.Body,
            Title = ( ( msg.RootMessage == null ) ? msg.Title : msg.RootMessage.Title ) ?? string.Empty
        };

Мы объявляем выражение, которое проектирует Message на MessageView (я удалил детали для ясности).

Теперь код доступа к данным может использовать это выражение для получения отдельного сообщения:

var query = CompiledQueryCache.Instance.GetCompiledQuery(
    "GetMessageView",
    () => CompiledQuery.Compile(
        _getMessagesExpr
            .Select( msg => _selectMessageViewExpr.Invoke( msg, userId ) ) // re-use the expression
            .FirstOrDefault( ( MessageView mv, int id ) => mv.MessageID == id )
            .Expand()
        )
    );

Это красиво, потому что одно и то же выражение можно повторно использовать для получения списка сообщений:

var query = CompiledQueryCache.Instance.GetCompiledQuery(
    "GetMessageViewList",
    () => CompiledQuery.Compile(
        BuildFolderExpr( folder )
            .Select( msg => _selectMessageViewExpr.Invoke( msg, userId ) )
            .OrderBy( mv => mv.DateCreated, SortDirection.Descending )
            .Paging()
            .Expand()
        ),
    folder
    );

Как вы можете видеть, проекционное выражение сохраняется в _selectMessageViewExpr и используется для создания нескольких разных запросов.

Однако я потратил много времени на отслеживание странной ошибки, когда этот код разбился на Expand() вызов.
Ошибка:

Невозможно передать объект типа System.Linq.Expressions.FieldExpression для ввода System.Linq.Expressions.LambdaExpression.

Только через некоторое время я понял, что работает, когда выражение ссылается на локальную переменную, прежде чем называться Invoke на:

var selector = _selectMessageViewExpr; // reference the field

var query = CompiledQueryCache.Instance.GetCompiledQuery(
    "GetMessageView",
    () => CompiledQuery.Compile(
        _getMessagesExpr
            .Select( msg => selector.Invoke( msg, userId ) ) // use the variable
            .FirstOrDefault( ( MessageView mv, int id ) => mv.MessageID == id )
            .Expand()
        )
    );

Этот код работает так, как ожидалось.

Мой вопрос:

Есть ли какая-то конкретная причина, почему LinqKit не распознает Invoke в выражениях, хранящихся в полях? Является ли это просто упущением разработчика, или есть какая-то важная причина, по которой нужно хранить выражения сначала в локальных переменных?

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

Спасибо.

Ответ 1

Я загрузил исходный код и попытался его проанализировать. ExpressionExpander не позволяет ссылаться на выражения, которые хранятся в переменных, отличных от константы. Он ожидает выражения, что метод Invoke вызывается для ссылки на объект, представленный ConstantExpression, а не другой MemberExpression.

Поэтому мы не можем предоставить наше многоразовое выражение в качестве ссылки на любой член класса (даже публичные поля, а не свойства). Доступ к членству в нем (например, object.member1.member2... и т.д.) Также не поддерживается.

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

Я заменил код метода TransformExpr класса ExpressionExpander на

var lambda = Expression.Lambda(input);
object value = lambda.Compile().DynamicInvoke();

if (value is Expression)
    return Visit((Expression)value);
else
    return input;

и теперь он работает.

В этом решении все, о чем я упоминал ранее (рекурсивное пересечение дерева), выполняется для нас с помощью ExpressionTree компилятора:)

Ответ 2

Я создал улучшенную версию Mic answer:

if (input == null)
    return input;

var field = input.Member as FieldInfo;
var prope = input.Member as PropertyInfo;
if ((field != null && field.FieldType.IsSubclassOf(typeof(Expression))) ||
    (prope != null && prope.PropertyType.IsSubclassOf(typeof(Expression))))
    return Visit(Expression.Lambda<Func<Expression>>(input).Compile()());

return input;

Главным преимуществом является удаление DynamicInvoke, у которого большие накладные расходы и вызов Invoke только тогда, когда он мне действительно нужен.