они работают, вам должно стать намного яснее, каким образом внутренне функционируют члены, сжатые до выражений. В главе 4 упоминалось, что в версии C# 6 появилась возможность использовать операцию => для упрощения некоторых реализаций членов. В частности, если есть метод или свойство (в дополнение к специальной операции или процедуре преобразования, как было показано в главе 11), реализация которого содержит единственную строку кода, тогда определять область действия посредством фигурных скобок необязательно. Взамен можно задействовать лямбда-операцию и написать член, сжатый до выражения. В версии C# 7 такой синтаксис можно применять для конструкторов и финализаторов классов (раскрываемых в главе 9), а также для средств доступа get и set к свойствам.
Тем не менее, имейте в виду, что новый сокращенный синтаксис может применяться где угодно, даже когда код не имеет никакого отношения к делегатам или событиям. Таким образом, например, если вы строите элементарный класс для сложения двух чисел, то могли бы написать следующий код:
class SimpleMath
{
public int Add(int x, int y)
{
return x + y;
}
public void PrintSum(int x, int y)
{
Console.WriteLine(x + y);
}
}
В качестве альтернативы теперь код может выглядеть так:
class SimpleMath
{
public int Add(int x, int y) => x + y;
public void PrintSum(int x, int y) => Console.WriteLine(x + y);
}
В идеале к этому моменту вы должны уловить суть лямбда-выражений и понимать, что они предлагают "функциональный способ" работы с анонимными методами и типами делегатов. Хотя на привыкание к лямбда-операции (=>) может уйти некоторое время, просто запомните, что лямбда-выражение сводится к следующей форме:
АргументыДляОбработки =>
{
ОбрабатывающиеОператоры
}
Или, если операция => используется для реализации члена типа с единственным оператором, то это будет выглядеть так:
ЧленТипа => ЕдинственныйОператорКода
Полезно отметить, что лямбда-выражения широко задействованы также в модели программирования LINQ, помогая упростить кодирование. Исследование LINQ начинается в главе 13.
Резюме
В настоящей главе вы получили представление о нескольких способах организации двустороннего взаимодействия для множества объектов. Во-первых, было рассмотрено ключевое слово delegate, которое применяется для косвенного конструирования класса, производного от System.MulticastDelegate. Вы узнали, что объект делегата поддерживает список методов для вызова тогда, когда ему об этом будет указано.
Во-вторых, вы ознакомились с ключевым словом event, которое в сочетании с типом делегата может упростить процесс отправки уведомлений ожидающим объектам. Как можно заметить в результирующем коде CIL, модель событий .NET отображается на скрытые обращения к типам System.Delegate/System.MulticastDelegate.
В данном отношении ключевое слово event является совершенно необязательным, т.к. оно просто позволяет сэкономить на наборе кода. Кроме того, вы видели, что null-условная операция C# 6.0 упрощает безопасное инициирование событий для любой заинтересованной стороны.
В-третьих, в главе также рассматривалось средство языка С#, которое называется анонимными методами. С помощью такой синтаксической конструкции можно явно ассоциировать блок операторов кода с заданным событием. Было показано, что анонимные методы вполне могут игнорировать параметры, переданные событием, и имеют доступ к "внешним переменным" определяющего их метода. Вы также освоили упрощенный подход к регистрации событий с применением групповых преобразований методов.
Наконец, в-четвертых, вы взглянули на лямбда-операцию (=>) языка С#. Как было показано, этот синтаксис представляет собой сокращенный способ для записи анонимных методов, когда набор аргументов может быть передан на обработку группе операторов. Любой метод внутри платформы .NET Core, который принимает объект делегата в качестве аргумента, может быть заменен связанным лямбда-выражением, что обычно несколько упрощает кодовую базу.
Глава 13
LINQ to Objects
Независимо от типа приложения, которое вы создаете с использованием платформы .NET Core, во время выполнения ваша программа непременно будет нуждаться в доступе к данным какой-нибудь формы. Разумеется, данные могут находиться в многочисленных местах, включая файлы XML, реляционные базы данных, коллекции в памяти и элементарные массивы. Исторически сложилось так, что в зависимости от места хранения данных программистам приходилось применять разные и несвязанные друг с другом API-интерфейсы. Набор технологий LINQ (Language Integrated Query — язык интегрированных запросов), появившийся в версии .NET 3.5, предоставил краткий, симметричный и строго типизированный способ доступа к широкому разнообразию хранилищ данных. В настоящей главе изучение LINQ начинается с исследования LINQ to Objects.
Прежде чем погрузиться в LINQ to Objects, в первой части главы предлагается обзор основных программных конструкций языка С#, которые делают возможным существование LINQ. По мере чтения главы вы убедитесь, насколько полезны (а иногда и обязательны) такие средства, как неявно типизированные переменные, синтаксис инициализации объектов, лямбда-выражения, расширяющие методы и анонимные типы.
После пересмотра поддерживающей инфраструктуры в оставшемся материале главы будет представлена модель программирования LINQ и объяснена ее роль в рамках платформы .NET. Вы узнаете, для чего предназначены операции и выражения запросов, позволяющие определять операторы, которые будут опрашивать источник данных с целью выдачи требуемого результирующего набора. Попутно будут строиться многочисленные примеры LINQ, взаимодействующие с данными в массивах и коллекциях различного типа (обобщенных и необобщенных), а также исследоваться сборки, пространства имен и типы, которые представляют API-интерфейс LINQ to Objects.
На заметку! Информация, приведенная в главе, послужит фундаментом для освоения материала последующих глав книги, включая Parallel LINQ (глава 15) и Entity Framework Core (главы 22 и 23) .
Программные конструкции, специфичные для LINQ
С высокоуровневой точки зрения LINQ можно трактовать как строго типизированный язык запросов, встроенный непосредственно в грамматику самого языка С#. Используя LINQ, можно создавать любое количество выражений, которые выглядят и ведут себя подобно SQL-запросам к базе данных. Однако запрос LINQ может применяться к любым хранилищам данных, включая хранилища, которые не имеют ничего общего с подлинными реляционными базами данных.
На заметку! Хотя запросы LINQ внешне похожи на запросы SQL, их синтаксис не идентичен. В действительности многие запросы LINQ имеют формат, прямо противоположный формату подобного запроса к базе данных! Если вы попытаетесь отобразить LINQ непосредственно на SQL, то определенно запутаетесь. Чтобы подобного не произошло, рекомендуется воспринимать запросы LINQ как уникальные операторы, которые просто случайно оказались похожими на SQL.
Когда LINQ впервые был представлен в составе платформы .NET 3.5, языки C# и VB уже были расширены
