Как получить значение ParameterExpression?

Question

[iRumba]

Мне нужно прокачать Ef Core (5). Есть некоторая функция в запросе, которая должна не транслироваться в БД функцию, а превратиться в в иную конструкцию (Expression).
Для этого я перехватил обход всего выражения через подмену сервисов EF.
Проблема в том, что функция принимает некий объект в качестве параметра и в моем визиторе я получаю MethodCallExpression с параметром ParameterExpression, который содержит имя параметра и тип. А для построения правильного выражения, мне нужно значение этого параметра.

Вот примерный код запроса

var myObject = new SomeObject();

ctx.MyEntity
    .Where(x => x.MyFunction(myObject))
    .ToList();

и вот этот самый myObject мне и нужен в моем визиторе. Если бы визитор я подключил прямо в функции запроса, я бы мог передать в него дополнительный параметр со значением объекта. Но тогда пришлось бы цеплять визитор к каждому запросу, а это неудобно, некрасиво и вообще атата.

Поэтому я в регистрации сервисов EF заменил QueryTranslationPreprocessor на свой.

Конструктор этого сервиса принимает в качестве параметров QueryTranslationPreprocessorDependencies и QueryCompilationContext.
Я пытался отыскать какую то возможность получить мой объект через эти объекты, но не нашел. Либо я плохо искал, либо через них нельзя.
Так же, первым выражением в переопределенный метод QueryTranslationPreprocessor.Process(Expression) приходит QueryRootExpression. в нем тоже пытался найти какое то ссылки на мой объект.

Так же, я сумел через IEvaluatableExpressionFilterPlugin запретить транслировать объекты типа SomeObject. После этого в мой визитор этот объект стал приходить как MemberExpression. Это уже ближе (возможно), так как это теперь не просто параметр, а выражение, содержащее MemberInfo. И этот объект является полем класса (сформированного от функции, внутри которой создается запрос). То есть для получения Member.GetValue() мне нужно передать туда экземпляр объекта типа Member.DeclaringType. Но где его взять я тоже не знаю.

Вероятно, я слишком сложно и абстрактно объяснил суть проблемы. Так что отвечу на наводящие вопросы.

Answer 1

[Влад]

Не понятно, к чему такие сложности? Почему заранее не собрать Expression и подкидывать его в фильтры по необходимости?

Comments

[iRumba]

Так я их и так заранее собираю. Только функцию `MyFunction` надо трансформировать в другой вид :)

Причем именно в другой вид, она не должна "как есть" транслироваться в SQL.

[Влад]

iRumba, так в том и суть. При нормальной работе LINQ выражение должно или преобразоваться к IEnumerable (тоесть LINQ to Object) или к алиасу sql функции. Я так понимаю что у вас есть функция, которую вы хотите засменить на Expression. В этом случае чтобы не заниматься вот этими извращениями, нужно было заранее собрать expressionы и передать в DbContext.DbSet<>.Where по условию.
Ну или хз, надо было лучше обьяснять, или привести синтетический пример.

[iRumba]

Вот вам синтетический пример.

У нас есть блог, в нем есть статьи, у статей есть комментарии. Блоги и комментарии привязаны к автору.

Пользователи могут находиться в бане.

Нужно построить 3 запроса: список забаненных пользователей (для админки), ленту статей, комментарии к статье.

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

var bannedUsers = ctx.Users.Where(x => x.IsBanned);

var postsLine = ctx.Posts.Where(x => !x.Blog.Author.IsBanned);

var comments = ctx.Comments.Where(x => x.Post.Id == postId && !x.Author.IsBanned);

Вот смотрите, во всех трех запросах используется одно и то же условие, забанен ли пользователь. Я не люблю подобное дублирование. И дело тут не только в эстетике. Завтра мне потребуется изменить механизм бана и вместо флага будет таблица банов (с датой начала и датой окончания). Придется лазить по всем местам, где используется это условие и менять. К тому же, если для банов будет таблица, проверка на бан будет несколько сложнее, чем с флагом, а значит будет шанс в каком-нибудь из запросов допустить ошибку, которая всплывет только в проде спустя какое то время (все зависит от наличия/качества автоматических тестов и ручного тестирования).

Поэтому, условие того, что пользователь забанен лучше хранить отдельно. Но как его использовать в трех этих запросах? Тут придется найти методы расширения для лямбда выражений (или написать самому), чтобы иметь возможность комбинировать предикаты. predicate1.And(predicate2).

Но тогда появится еще одна проблема. Предикат для забаненных пользователей имеет входящий тип User. А в этом запросе var postsLine = ctx.Posts.Where(x => !x.Blog.Author.IsBanned); входящий тип Post. В итоге, после всех магических финтов с выражениями (на более серьезных запросах), запрос может стать не очень выразительным. А некоторые условия вообще требуют параметры (идентификатор, дата и другие).

Наши изыскания привели нас к библиотеке NSpecification, которая реализует паттерн спецификация и содержит в себе тип Specification. Тип этот имеет свойство типа LambdaExpression (конечно же дженерик) и позволяет применять к спецификациям логические операции & |. Это позволяет делать такие финты, которые с чистыми Expression не сделать. Например, можно состряпать новую спецификацию на основе двух других с синтаксисом spec1 & spec2. Это удовольствие сомнительное, но это не единственная плюха.

Еще есть неявное приведение к Expression.

Есть у них полезные функции. Например, метод расширения для Object функция Is.

public static bool Is(this object obj, Specification spec)

Это позволяет выполнять такие штуки theUser.Is(banned). То есть запрос на получение комментов мог выглядеть как то так.

var commentsByPostSpecification = new CommentsByPostSpecification(postId);
var commentsWithoutBannedSpecification = new Specification<Comment>(x => x.Author.Is(new BannedUserSpecification()));

var comments = ctx.Comments.Where(commentsByPostSpecification & commentsWithoutBannedSpecification);

Все прозрачно, каждую хранимую спецификацию можно покрыть тестами, красота!

Вот только метод Is (чуть выше используется x => x.Author.Is(new BannedUserSpecification())) нужно трансформировать, чтобы получилось валидное выражение, понятное транслятору в SQL. При этом очень не хочется каждый предикат, использующий выше описанную функцию, пропускать через визитор. Это не то место, где нужна прозрачность, поэтому я и хочу расширить возможности EF для работы с этими функциями.

[Влад]

iRumba, Ну что я могу сказать. Используйте обьекты фильтров, их поддерживать легче.

[iRumba]

Они никак не отменят дублирование. К тому же уже много запросов со спецификациями, поздно переобуваться.