Принципы работы IQueryable и LINQ-провайдеров данных

Средства LINQ позволяют .Net-разработчикам единообразно работать как с коллекциями объектов в памяти, так и с объектами, хранящимися в базе данных или ином удаленном источнике. Например, для запроса десяти красных яблок из списка в памяти и из БД средствами Entity Framework мы можем использовать абсолютно идентичный код:

List<Apple> appleList;  DbSet<Apple> appleDbSet; var applesFromList = appleList.Where(apple => apple.Color == “red”).Take(10); var applesFromDb = appleDbSet.Where(apple => apple.Color == “red”).Take(10); 

Однако, выполняются эти запросы по-разному. В первом случае при перечислении результата с помощью foreach яблоки будут отфильтрованы с помощью заданного предиката, после чего будут взяты первые 10 из них. Во втором случае синтаксическое дерево с выражением запроса будет передано специальному LINQ-провайдеру, который транслирует его в SQL-запрос к базе данных и выполнит, после чего сформирует для 10 найденных записей объекты С# и вернет их. Обеспечить такое поведение позволяет интерфейс IQueryable<T>, предназначенный для создания LINQ-провайдеров к внешним источникам данных. Ниже мы попробуем разобраться с принципами организации и использования этого интерфейса.

Интерфейсы IEnumerable<T> и IQueryable<T>

На первый взгляд может показаться, что в основе LINQ лежит набор методов-расширений вроде Where(), Select(), First(), Count() и т.д. к интерфейсу IEnumerable<T>, что в итоге дает разработчику возможность единообразно писать запросы как к объектам в памяти (LINQ to Objects), так и к базам данных (например, LINQ to SQL, LINQ to Entities) и удаленным сервисам (например, LINQ to OData Services). Но это не так. Дело в том, что внутри методов-расширений к IEnumerable<T> уже реализованы соответствующие операции с последовательностями. Так, например, метод First<TSource>(Func<TSource, bool> predicate) реализован в .Net Framework 4.5.2, исходники которого нам доступны здесь, следующим образом:

public static TSource First<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {     if (source == null) throw Error.ArgumentNull("source");     if (predicate == null) throw Error.ArgumentNull("predicate");     foreach (TSource element in source) {           if (predicate(element)) return element;     }     throw Error.NoMatch(); } 

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

Для реализации LINQ-провайдеров к внешним по отношению к приложению данным используется интерфейс IQueryable<T> (наследник от IEnumerable<T>) вместе с набором методов-расширений, почти полностью идентичных тем, что написаны для IEnumerable<T>. Именно потому, что List<T> реализует IEnumerable<T>, а DbSet<T> из Entity Framework – IQueryable<T>, приведенные в начале статьи запросы с яблоками выполняются по-разному.

Особенность методов-расширений к IQueryable<T> состоит в том, что они не содержат логики обработки данных. Вместо этого они просто формируют синтаксическую структуру с описанием запроса, «наращивая» ее при каждом новом вызове метода в цепочке. При вызове же агрегатных методов (Count() и т.п.) или при перечислении с помощью foreach описание запроса передается на выполнение провайдеру, инкапсулированному внутри конкретной реализации IQueryable<T>, а тот уже преобразует запрос в язык источника данных, с которым работает, и выполняет его. В случае с Entity Framework таким языком является SQL, в случае с .Net-драйвером для MongoDb – это поисковый json-объект и т.д.

Кстати говоря, из этой особенности вытекают некоторые «интересные» характеристики LINQ-провайдеров:

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

Делаем LINQ своими руками: ISimpleQueryable<T>

Прежде чем описывать устройство интерфейса IQueryable<T>, попробуем самостоятельно написать его простой аналог – интерфейс ISimpleQueryable<T>, а также пару методов-расширений к нему в стиле LINQ. Это позволит наглядно продемонстрировать основные принципы работы с IQueryable<T>, не вдаваясь пока в нюансы его реализации.

public interface ISimpleQueryable<TSource> : IEnumerable<TSource> {     string QueryDescription { get; }     ISimpleQueryable<TSource> CreateNewQueryable(string queryDescription);     TResult Execute<TResult>(); } 

В интерфейсе мы видим свойство QueryDescription, которое содержит описание запроса, а также метод Execute<TResult>(), который должен этот запрос при необходимости выполнить. Это generic-метод, поскольку результат выполнения может быть как перечислением, так и значением агрегатной функции, такой как Count(). Кроме того, в интерфейсе есть метод CreateNewQueryable(), который позволяет при добавлении нового LINQ-метода сформировать новый экземпляр ISimpleQueryable<T>, но уже с новым описанием запроса. Заметим, что описание запроса здесь представлено в виде строки, а в LINQ для этого используются деревья выражений (Expression Trees), о которых можно почитать здесь или здесь.

Теперь перейдем к методам-расширениям:

public static class SimpleQueryableExtentions  {     public static ISimpleQueryable<TSource> Where<TSource>(this ISimpleQueryable<TSource> queryable,                                                             Expression<Func<TSource, bool>> predicate) {         string newQueryDescription = queryable.QueryDescription + ".Where(" + predicate.ToString() + ")";         return queryable.CreateNewQueryable(newQueryDescription);     }        public static int Count<TSource>(this ISimpleQueryable<TSource> queryable) {         string newQueryDescription = queryable.QueryDescription + ".Count()";         ISimpleQueryable<TSource> newQueryable = queryable.CreateNewQueryable(newQueryDescription);         return newQueryable.Execute<int>();     } } 

Как мы видим, эти методы просто дописывают информацию о себе в описание запроса и создают новый экземпляр ISimpleQueryable<T>. Кроме того, метод Where(), в отличие от своего аналога для IEnumerable<T>, принимает не сам предикат Func<TSource, bool>, а упомянутое ранее дерево выражения (expression tree) с его описанием Expression<Func<TSource, bool>>. В данном примере это просто дает нам возможность получить строку с кодом предиката, а в случае с реальным LINQ – возможность сохранить все детали запроса в виде дерева выражений.

Наконец, создадим простую реализацию нашего ISimpleQueryable<T>, которая будет содержать все необходимое для написания LINQ-запросов, за исключением метода их выполнения. Для придания реалистичности добавим туда ссылку на источник данных (_dataSource), которая должна использоваться при выполнении запроса методом Execute().

public class FakeSimpleQueryable<TSource> : ISimpleQueryable<TSource> {     private readonly object _dataSource;     public string QueryDescription { get; private set; }      public FakeSimpleQueryable(string queryDescription, object dataSource) {         _dataSource = dataSource;         QueryDescription = queryDescription;     }          public ISimpleQueryable<TSource> CreateNewQueryable(string queryDescription) {         return new FakeSimpleQueryable<TSource>(queryDescription, _dataSource);     }      public TResult Execute<TResult>() {         //Здесь должна быть обработка QueryDescription и применение запроса к dataSource         throw new NotImplementedException();     }          public IEnumerator<TSource> GetEnumerator() {         return Execute<IEnumerator<TSource>>();     }      IEnumerator IEnumerable.GetEnumerator() {         return GetEnumerator();     } } 

Теперь рассмотрим простой запрос к FakeSimpleQueryable:

var provider = new FakeSimpleQueryable<string>("", null); int result = provider.Where(s => s.Contains("substring")).Where(s => s != "some string").Count(); 

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

• сначала первый вызов метода Where() возьмет у созданного с помощью конструктора экземпляра FakeSimpleQueryable пустое описание запроса, добавит к нему ".Where(s => s.Contains(«substring»))" и сформирует второй экземпляр FakeSimpleQueryable с новым описанием;
• затем второй вызов Where() возьмет у созданного ранее FakeSimpleQueryable описание запроса, добавит к нему ".Where(s => s != «some string»)", после чего опять сформирует новый, третий по счету, экземпляр FakeSimpleQueryable с описанием запроса ".Where(s => s.Contains(«substring»)).Where(s => s != «some string»)";
• наконец, вызов Count() возьмет у созданного на предыдущем шаге экземпляра FakeSimpleQueryable описание запроса, добавит к нему " .Count()" и сформирует четвертый экземпляр FakeSimpleQueryable, после чего вызовет у него метод Execute<int>, поскольку дальше построение запроса невозможно;
• в результате внутри метода Execute() мы будет иметь значение QueryDescription, равное ".Where(s => s.Contains(«substring»)).Where(s => s != «some string»).Count()", которое и нужно обрабатывать дальше.

Настоящий IQueryable<T>… и IQueryProvider<T>

Рассмотрим теперь, что собой представляет интерфейс IQueryable<T>, реализованный в .Net:

public interface IQueryable : IEnumerable {     Expression Expression { get; }     Type ElementType { get; }     IQueryProvider Provider { get; } }   public interface IQueryable<out T> : IEnumerable<T>, IQueryable {}   public interface IQueryProvider {     IQueryable CreateQuery(Expression expression);     IQueryable<TElement> CreateQuery<TElement>(Expression expression);     object Execute(Expression expression);     TResult Execute<TResult>(Expression expression); } 

Отметим, что:

• в .Net есть generic- и обычная версия IQueryable;
• для хранения дерева с описанием LINQ-запроса используется свойство Expression (в нашей реализации мы использовали строчное QueryDescription);
• свойство ElementType содержит информацию о типе возвращаемых запросом элементов и используется в реализациях LINQ-провайдеров для проверки соответствия типов;
• пара методов по созданию новых экземпляров IQueryable (CreateQuery() и CreateQuery<TElement>()), а также пара методов по выполнению запроса (Execute() и Execute<TResult>()) вынесены в отдельный интерфейс IQueryProvider<T>; можно предположить, что такое разделение понадобилось для того, чтобы отделить сам запрос, который пересоздается при каждом новом вызове метода-расширения, от того объекта, который реально имеет доступ к источнику данных, делает всю основную работу и может быть достаточно «тяжеловесным» для постоянного пересоздания;
• свойство IQueryable.Provider указывает на связанный экземпляр IQueryProvider.

Теперь рассмотрим работу методов-расширений к IQueryable<T> на примере метода Where():

public static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, int, bool>> predicate) {     if (source == null) throw Error.ArgumentNull("source");     if (predicate == null) throw Error.ArgumentNull("predicate");     return source.Provider.CreateQuery<TSource>(          Expression.Call(            null,             ((MethodInfo)MethodBase.GetCurrentMethod()).MakeGenericMethod(typeof(TSource)),             new Expression[] { source.Expression, Expression.Quote(predicate) }            )); } 

Мы видим, что метод конструирует новый экземпляр IQueryable<TSource>, передавая в CreateQuery<TSource>() выражение, в котором к исходному выражению из source.Expression добавлен вызов собственно метода Where() с переданным предикатом в качестве аргумента.

Таким образом, несмотря на некоторые отличия интерфейсов IQueryable<T> и IQueryProvider<T> от созданного нами ранее ISimpleQueryable<T>, принципы их использования в LINQ те же: каждый метод-расширение, добавленный к запросу, дополняет дерево выражений информацией о себе, после чего создает новый экземпляр IQueryable<T> с помощью метода CreateQuery<T>(), а агрегатные методы, кроме того, инициируют выполнение запроса, вызывая метод Execute<T>().

Пара слов о разработке LINQ-провайдеров

Поскольку механизм конструирования LINQ-запроса уже реализован в .Net за нас, то разработка LINQ-провайдера в большинстве своем сводится к реализации методов Execute() и Execute<TResult>(). Именно здесь требуется разобрать пришедшее на выполнение expression tree, сконвертировать его в язык источника данных, выполнить запрос, обернуть результаты в C#-объекты и вернуть их. К сожалению, эта процедура включает в себя обработку немалого количества различных нюансов. Более того, доступной информации по разработке LINQ-провайдеров довольно мало. Ниже приведены наиболее информативные, по мнению автора, статьи на эту тему:

• LINQ: Building an IQueryable provider series,
• Walkthrough: Creating an IQueryable LINQ Provider

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

ссылка на оригинал статьи http://habrahabr.ru/post/256821/