Урок 7. LINQ в C# .NET — революция в обработке запросов
В предыдущих упражнениях задания 5.-6. На уроке работы с коллекциями в C# .NET мы отрабатывали опыт, полученный на предыдущих уроках.
В сегодняшнем руководстве по C# .NET мы сосредоточимся на технологии LINQ, которая представляет собой набор инструментов для запроса данных. Это очень революционная технология, упрощающая и обобщающая работу с любыми данными.
Мотивация
Конечно, мы все по-разному работали с разными типами коллекций. В противном случае мы бы искали элемент в массиве, иначе мы считывали бы данные из XML-файла, иначе мы искали бы пользователя в базе данных. Но представьте, если бы был один унифицированный способ запроса данных. Если бы мы могли выполнить один и тот же запрос как для обычного поля, так и для XML-файла или базы данных. Вы, наверное, догадываетесь, что LINQ предоставляет нам именно такой комфорт. Это огромная абстракция, которая компенсируется лишь незначительным снижением производительности и которая подтолкнула программистов на C# к новым высотам.
LINQ как язык
LINQ — относительно сложная и широко распространенная технология. Его название происходит от интегрированного запроса английского языка. Как следует из названия, это язык запросов, интегрированный непосредственно в синтаксис C#. Это часть его, начиная с C# 3.0 и .NET framework 3.5. В более новых версиях количество волокон еще больше, что увеличивает эффективность этой технологии.
LINQ очень похож на SQL и поэтому является декларативным языком. Мы сообщаем программе, что мы ищем, и нам все равно, как она на самом деле ищет данные для нас. Преимуществом интеграции LINQ в C# является синтаксическая проверка запросов во время компиляции программы.
Прежде чем идти дальше, давайте приведем небольшой пример. Запустите новый проект, это будет консольное приложение под названием LINQ. Давайте создадим простое поле текста для чтения.
Теперь с помощью LINQ-запроса мы выбираем из этого поля те элементы, длина которых превышает 5 букв. Добавьте в программу следующий код:
Запрос заметно напоминает SQL, те, кто его знает, имеют преимущество. Я не думаю, что вы уже вызывали SQL для массива, не так ли? 
Мы сразу подробно прочитаем запрос, но сначала завершим нашу программу выводом результата запроса в консоль:
Как выглядит запрос
Вернемся к нашему вопросу, который выглядел так:
Эксперты по SQL наверняка удивятся тому, что запрос запаздывает. Оно имеет свое обоснование, к которому мы и придем.
Сначала мы определяем, откуда мы будем выбирать данные, используя ключевое слово from. После from идет переменная, которая будет представлять элемент из коллекции в остальной части запроса. Далее идет ключевое слово и сама коллекция. Это похоже на цикл foreach. Вопросы будут разбиты на несколько строк, чтобы было понятно. Цените это, особенно сложные.
Для условия мы можем включить строку с ключевым словом where , за которой следует условие. Условия в этом случае полностью такие же, как мы делали до сих пор.
Ключевое слово select следует за последней строкой, с помощью которого мы определяем, что мы выбираем. Здесь мы выбираем весь элемент из коллекции, т.е. j . Точно так же мы могли бы выбрать только его длину j.Length или что-то еще.
Вариант ключевого слова
Мы храним запрос в переменной типа var, с таким типом мы еще не сталкивались и это даже не тип данных.Ключевое слово var позволяет нам оставить выбор типа данных компилятору (помните, что код C# делает это за нас во время трансляции). Теоретически мы могли бы использовать var, например, по-другому. следующим образом:
Код на C# по сути сводится к следующему:
Таким образом, ключевое слово var позволяет нам определить тип данных даже при переводе программы и фактически отделяет нас от типа данных. В обычных программах это было бы затруднительно, так как спецификация типа имеет свое значение. Так что будем продолжать писать типы и ни в коем случае не заменять их словом var, как некоторые новички узнают по ошибке.
Ключевое слово var было введено для LINQ по следующим причинам:
- Во-первых, типы данных запроса относительно сложны, и было бы сложно всегда указывать их явно.
- Во-вторых, когда мы меняем тип коллекции, меняется и тип запроса, что требует ненужного редактирования кода и снижает универсальность технологии.
- Теперь с помощью LINQ мы скоро доберемся до так называемых анонимных типов, без которых мы не можем обойтись без vars.
Необходимо помнить, что var используется главным образом в вопросах и не должен появляться в обычном коде , даже если теоретически может там использоваться.
Общее правило состоит в том, что мы можем использовать var в случае упрощения объявления и при этом все равно понятно, какого типа переменная. Покажем 4 примера без var и с var :
Используя var, мы можем изменить код следующим образом:
Для первой переменной кипячение не приводит ни к какому упрощению. С другой стороны, для общего листа общих словарей его использование окупается, и, поскольку мы также можем видеть, к какому типу относится переменная словаря с правой стороны, var также является хорошим выбором здесь.Однако лучше было бы написать что-то подобное, хранение коллекций коллекций — тоже плохая практика. Для запроса LINQ тип сложный, и если мы скажем удаленный orderby, он изменится на IQueryable. Таким образом, нам не нужно перебирать тип преобразования или менять его вместе с запросом. Последнее использование var — это удаление, мы вообще не знаем из строки, что мы храним в переменной b.
Еще одна распространенная ошибка заключается в том, что люди думают, будто переменная var объявляет переменную динамического типа, то есть мы можем хранить в ней все, что захотим. Это не так, тип фиксируется при переводе и не может быть изменен во время работы программы. Если нет, то работать не будет:
Программа создает строковую переменную, а затем аварийно завершает работу, потому что мы пытаемся сохранить целое число в строковом типе.
Под капотом
Как все это работает? Если вы посмотрите на начало вашего исходного кода, вы увидите, что он содержит следующее использование:
Это предпочтительнее для всех типов проектов. Попробуем его закомментировать, в этот момент Visual Studio подчеркнет имя переменной в запросе.
LINQ работает с помощью так называемого провайдера , которого существует несколько типов, а также можно определить свой собственный. Теперь мы используем LINQ To Objects , который реализован непосредственно в пространстве имен System.Linq и разрешает общие коллекции, такие как строки. массивы и листы с дополнительными методами. Поэтому методы растворения находятся в стадии рассмотрения.
Теперь попробуем (закомментировано с помощью em) вызвать меню методов для нашего поля. Напишем имена. (имя и символ)., чтобы вызвать список методов в поле:
Теперь давайте снова раскомментируем код и повторим то же самое:
В обычной области у нас внезапно появилось множество новых методов. Когда С#выполняет запрос LINQ, вызывает эти методы в фоновом режиме для коллекции. Они создаются с помощью лямбда-шоков, с которыми мы уже встречались в курсе ООП.
поэтому C# преобразуется и генерирует следующий код:
Вы можете проверить, будет ли запрос работать так же. Мы можем работать с LINQ таким же образом, но с помощью SQL-подобного списка это намного удобнее. Кстати, мы только что объяснили, почему в запросе сначала идет where, а потом select. Данные должны быть сначала найдены с помощью метода Where(), и только потом то, что нас интересует, может быть объявлено из результата с помощью метода Select(). Причина, таким образом, заключается в последовательности методов под видом технологии.
В заключение расскажем, чем обернулся в нашем случае этот загадочный вид фурункула. Результирующий тип запроса для нашего поля:
Поскольку мы не можем заранее знать, какой тип LINQ нам возвращать (точнее, мы должны быть из него удалены), был введен тип var, как это и было задумано.
Были ли у вас проблемы? Загрузите приведенный ниже образец приложения и сравните его со своим проектом, чтобы легко найти ошибку.
Скачать
Загружено 512x (23,17 КБ)
Приложение включает исходный код на языке C#
