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

Вы когда-нибудь работали с 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
  That’s right: I haven’t.
  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)));
}

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

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

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

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

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

Out Of Process

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

Для GraphQl, вотличие от OData, я не видел примеров реализации, вроде этого:

[EnableQuery()]  // requires using Microsoft.AspNet.OData;
[HttpGet]
public ActionResult<IQueryable<TodoItem>> GetTodoItems()
{
    return _context.TodoItems;
}

Однако, для построения сложных фильтраций/проекций под капотом зачастую используется IQueryable.

// pure code first
public class Query {
    [UseFiltering("SqlServer")]
    public IQueryable<Foo> Foos([Service]DbContext context) => context.Foos;
}
//code first
public class Query : ObjectType {
    protected override void Configure(IObjectTypeDescriptor descriptor) {
        descriptor
            .Field<Resolver>(x => x.Foos(default!))
            .UseFiltering("SqlServer");
    }
    public class Resolver {
        public IQueryable<Foo> Foos([Service]DbContext context) => context.Foos;
    }
}

Речь не о том, что они явно раскрывают наружу интерфейс, а в том, что .NET-реализации протоколов часто на него полагаются, потому что оба протокола, по сути, представляют язык запросов, который, зачастую, сложно реализовать полностью. В итоге API может стать хрупким по мере наращивания возможностей.

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();

   // но работает, если заинлайнить
   public static object WorksAgain(IQueryable<User> users) =>
       users
           .Where(x => x.FirstName.StartsWith("М"))
           .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, а что нет — это та еще кроличья нора. Например, обобщенные методы (дженерики) в ряде случаев будут добавлять в дерево выражений приведения к типу (Expression.Convert) там, где этого вы совсем не ждете. Чтобы это обойти придется либо создавать деревья вручную, либо эксплуатировать DLR, чтобы вызвать наиболее специализированные методы в runtime. К тому же, нет никакой гарантии, что в новых версиях ORM правила трансляции не будут изменены, как это уже случалось много раз.

Подзапросы

А что если в IQueryable сунуть другой IQueryable? Чаще всего все будет нормально. ORM транслирует такое в позапросы, т.е. будет нечто вроде:

select tmp.* from (select from * table) as tmp

Но и здесь нас могут поджидать неприятности: все IQueryable должны быть получены из одного DbContext. Так что если вы решили создать несколько контекстов, чтобы запустить параллельное выполнение через Task.WhenAll, то придется общие IQueryable получать из фабричных методов, чтобы у каждого таска был IQueryable, ассоциированный со своим контекстом. Тот факт, что не все реализации IQueryable одинаково полезны взаимозаменяемы в подзапросах подводит нас к следующему параграфу.

Queryable.AsQueryable

public static IQueryable<TElement> AsQueryable<TElement>(this IEnumerable<TElement> source) {
    if (source == null)
        throw Error.ArgumentNull("source");
    if (source is IQueryable<TElement>)
        return (IQueryable<TElement>)source;
    return new EnumerableQuery<TElement>(source);
}

Забудьте о существовании этого метода… серьезно, забудьте. EnumerableQuery<TElement> — это заглушка. Она ничего никуда не транслирует, а просто компилирует выражения в делегаты и выполняет все запросы в памяти.

internal T Execute(){
    if (this.func == null){
        EnumerableRewriter rewriter = new EnumerableRewriter();
        Expression body = rewriter.Visit(this.expression);
        Expression<Func<T>> f = Expression.Lambda<Func<T>>(
            body,
            (IEnumerable<ParameterExpression>)null);
        this.func = f.Compile();
    }
    return this.func();
}

Если вы попытаетесь использовать такую реализацию в подзапросах, то получите ошибку, аналогичную той, что происходит при попытке использования DbSet из другого контекста. Зачастую текст ошибки заставляет пойти по ложному следу поисков проблем с циклом жизни DbContext и провести пару-тройку часов в отладке, пока не будет найдена вредоносная строчка.

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

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

FullName => FirstName + " " + LastName

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

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

[NotMapped]

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

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

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

Проекции

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

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

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

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

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

public static object ProjectionWorksOrNot (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-стиле.

Выводы

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