Русский
Русский
English
Статистика
Реклама

Транслируй меня полностью


Вы когда-нибудь работали с Entity Framework или другим ORM и получали NotSupportedException? Многие люди получали:


InvalidOperationException: Error generated for warning 'Microsoft.EntityFrameworkCore.Query.QueryClientEvaluationWarning: The LINQ expression could not be translated and will be evaluated locally.'

Марк Симан твердо убежден, что, за одним исключением, все существующие реализации нарушают LSP. Он даже готов отправить бесплатную копию своей книги первому читателю, который укажет ему на реальную, общедоступную реализацию IQueryable<T>, которая может принять любое выражение и не выбросить исключение. За девять лет книга так и не нашла своего обладателя:)


  • Hi Mark,
    I am writing a blog post that refers to your artticle. I am wondering if you have ever sent a free copy of your book to someone. Presumably not:)
  • Hi Maxim
    Thats right: I havent.
    Regards
    Mark Seemann

В поддержку этой точки зрения можно привести и другие аргументы. Например, ToListAsync вообще отсутствует в наборе методов расширения из коробки. Вместо этого он определен в пакетах конкретных ORM. Значит ли это, что не стоит раскрывать IQueryable<T> в публичных API? Я думаю, что ответ на этот вопрос зависит


ToListAsync


Для начала разберемся с ToListAsync. Здесь все однозначно. Метод построен на попытке привести IQueryable<TSource> к IAsyncEnumerable<TSource> с помощью метода AsAsyncEnumerable:


public static async Task<List<TSource>> ToListAsync<TSource>(   [NotNull] this IQueryable<TSource> source,   CancellationToken cancellationToken = default){   var list = new List<TSource>();   await foreach (var element in source.AsAsyncEnumerable().WithCancellation(cancellationToken))   {       list.Add(element);   }   return list;}

Который, в свою очередь, выбрасывает исключение, если аргумент не реализует соответствующий интерфейс:


public static IAsyncEnumerable<TSource> AsAsyncEnumerable<TSource>(   [NotNull] this IQueryable<TSource> source){   Check.NotNull(source, nameof(source));   if (source is IAsyncEnumerable<TSource> asyncEnumerable)   {       return asyncEnumerable;   }   throw new InvalidOperationException(CoreStrings.IQueryableNotAsync(typeof(TSource)));}

Не очень-то заменимы реализации этого интерфейса. Да, можно обложить этот метод еще одной оберткой и в случае отсутствия интерфейса завернуть синхронный метод в Task.FromResult, но это позиция обезьянок на картинке для привлечения внимания.


Раскрывать ли IQueryable в public API?


Пишем IQueryable держим Entity Framework / NHibernate / Linq2Db в уме. Почти никогда в рамках одного проекта не используется больше одной ORM. Замена одной ORM на другую крайне редкое и невероятно затратное мероприятие.


Связка Linq2Db и Entity Framework кажется многообещающей, но я ее не пробовал в реальных проектах, поэтому рекомендовать не могу.

Фасад из протекающей абстракции, к сожалению, никак не меняет этого факта. Поэтому вопрос в заголовке можно переформулировать как раскрывать ли зависимости от фреймворка в API?


Out Of Process


Я думаю, что светить IQueryable за пределами вашего приложения скорее неудачная идея. Поэтому я настороженно отношусь к GraphQl или OData. Безусловно, существуют сценарии, когда использование этих технологий может быть оправдано. Однако, обычные rest-like API гораздо проще в разработке, поддержке и использовании. Даже если методов для фильтрации достаточно много Query Objects все еще могут неплохо справляться со своей задачей с минимальным дублированием кода.


In process


Что касается передачи IQueryable во внутренних слоях приложения, я думаю, что этот сценарий допустим, при условии, что такой объект появился в результате рефакторинга. Бывают случаи, когда условия получения данных настолько запутаны и сложны, что одними спецификациями выразить их не получается. Приходится создавать промежуточные слои la DataQueryHandler в терминологии CQRS/Vertical Slices. В этом случае передача IQueryable допустимо, просто потому что остальные варианты еще хуже.


Что учесть при работе с IQueryable


Мы условились, что под IQueryable всегда понимается реализация конкретного поставщика запросов. Поэтому, придется учитывать его ограничения. Будем рассматривать варианты запросов на примере вот такого простого класса пользователя:


public enum UserType: byte{   Regular,   Vip}public class User : IdentityUser{   [NotMapped]   public int Age { get; set; }   public Organization Organization { get; set; }   public UserType UserType { get; set; }   public string FirstName { get; set; }   public string LastName { get; set; }   public string FullName => $"{FirstName} {LastName}";}

Вызов методов


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


public static class Demo{   public static bool Filter(User user) =>           user.FirstName.StartsWith("М");   public static object Works(IEnumerable<User> users) =>       users           .Where(x => Filter(x))           .ToList();     public static object ThrowsException(IQueryable<User> users) =>       users           .Where(x => Filter(x))           .ToList();}

Если вы не понимаете, почему одинаковые (на самом деле нет) LINQ-выражения в одном случае работают, а в другом нет, посмотрите или почитайте мой доклад о деревьях выражений и попробуйте написать Visitor, чтобы посмотреть разницу в выражениях. Должно стать понятно.

К сожалению, Мадс Торгерсен подтвердил мне в ходе Q&A сессии DotNext Moscow 2020, что у них нет планов по реализации декомпилятора делегатов в выражения в BCL. Кроме того, существуют объективные технические сложности для реализации такого метода. Поэтому, у ORM нет простых способов заинлайнить методы в выражении. В какой SQL должен транслироваться вызов функции Filter? В общем случае ответ да хрен его знает. Ровно поэтому поставщики запросов и выбрасывают исключения.


Вы можете подсказать Entity Framework, что такая функция есть у вас в БД. В этому случае есть смысл объявить об этом явно:


public static class DbFunctions{   public static bool Filter(User user) =>           user.FirstName.StartsWith("М"); }//...       users           .Where(DbFunctions.Filter)           .ToList();

Исключения, подтверждающее правило


public static object Exception (IQueryable<User> users) =>   users       .Where(x => x.FirstName.StartsWith("М"))       .ToList();

Метод StartsWith или Contains будут транслироваться, потому что трансляция этих методов в SQL достаточно проста: LIKE М% и LIKE %М%, соответственно. Важное различие заключается в том, что эти методы входят в BCL и поставщики типов знают об их существовании на этапе компиляции. Кроме этого, вы никогда не застрахованы от неожиданностей вроде:


// падаетpublic static object EnumException (IQueryable<User> users) =>   users       .Select(x => x.UserType.ToString())       .Distinct()       .ToList();// а так работаетpublic static object EnumWorks (IQueryable<User> users) =>   users       .Select(x => ((byte)x.UserType).ToString())       .Distinct()       .ToList();

Видимо, приведение к Underlying Type позволяет проигнорировать создание Enum как такового и интерпретировать ToString как обычный Convert.


Вообще, что именно будет транслировано в плане MethodCallExpression, а что нет это та еще кроличья нора. К тому же, нет никакой гарантии, что в новых версиях ORM правила трансляции не будут изменены, как это уже случалось много раз.

[NotMapped]


Здесь все очевидно. Если поле не имеет отражения на БД, то и транслировать такое выражение не во что:


public static object NotMappedException (IQueryable<User> users) =>   users       .Where(x => x.Age > 18)       .ToList();

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


Конструктор


И на закуску еще сценарий, часто вводящих в ступор. Вот такое выражение транслируется последними версиями EF Core (может транслируется и в EF 6, напишите в комментариях, если знаете точно):


public static object ConstructorWorks (IQueryable<User> users) =>   users       .Select(x => x.FullName)       .ToList();

А вот такой уже нет:


public static object ConstructorException (IQueryable<User> users) =>   users       .Where(x => x.FullName.StartsWith("М"))          .Select(x => x.FullName)       .ToList();

Это связано с оптимизацией EF Core. Если Select не получается транслировать, то он может вытащить всю сущность и выполнить вызов x => x.FullName уже в памяти. Оптимизация может приводить к более изощенным казусам, вроде:


public static object OrganizationWorksOrNot (IQueryable<User> users) =>   users       .Select(x => new { x.Organization.FullName })       //.Where(x => x.FullName.StartsWith("М"))        .ToList();

Код выше может работать или падать с ошибкой, в зависимости от того, что еще входит в выражение. Еще хуже все становится, если где-то в Select попадают сущности целиком. В этом случае успех операции может зависеть от того включен ли Lazy Loading или указан ли Include.


Вообще Include в сочетание с Select это либо тот еще запашок, либо полное непонимание того, что проекции не попадают в change tracker (если вы не инициализируете свойства проекции классами сущностей). Вообще, по поводу Include и Lazy Loading очень рекомендую статью In Defense of Lazy Loading, особенно если вы хотите структурировать бизнес-логику в DDD-стиле.

Интерполяция строк


Это еще несколько палок в колеса. Я не буду подробно останавливаться на деталях, потому что они уже прекрасно описаны в статье Помогаем Queryable Provider разобраться с интерполированными строками. Замечу лишь, что:


FullName => FirstName + " " + LastName

гораздо безопаснее, чем


FullName => $"{FirstName} {LastName}"

Выводы


Использование IQueryable во внутренних API допустимо, но сопряжено с неожиданностями. Чего больше: плюсов или минусов каждый решает сам для себя. Делитесь в комментариях вашим опытом увлекательной отладки нетранслируемых запросов. Добавим интересные истории в статью, чтобы жить C#-программистам стало чуточку легче.

Источник: habr.com
К списку статей
Опубликовано: 24.02.2021 14:21:40
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Net

C

Iqueryable

Iqueryprovider

Expression trees

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru