await foreach (var number in GenerateSequence())
{
Console.WriteLine(number);
}
Итоговые сведения о ключевых словах async и await
Настоящий раздел содержал много примеров; ниже перечислены ключевые моменты, которые в нем рассматривались.
• Методы (а также лямбда-выражения или анонимные методы) могут быть помечены ключевым словом async, что позволяет им работать в неблокирующей манере.
• Методы (а также лямбда-выражения или анонимные методы), помеченные ключевым словом async, будут выполняться синхронно до тех пор, пока не встретится ключевое слово await.
• Один метод async может иметь множество контекстов await.
• Когда встречается выражение await, вызывающий поток приостанавливается до тех пор, пока ожидаемая задача не завершится. Тем временем управление возвращается коду, вызвавшему метод.
• Ключевое слово await будет скрывать с глаз возвращаемый объект Task, что выглядит как прямой возврат лежащего в основе возвращаемого значения. Методы, не имеющие возвращаемого значения, просто возвращают void.
• Проверка параметров и другая обработка ошибок должна делаться в главной части метода с переносом фактической порции async в закрытую функцию.
• Для переменных, находящихся в стеке, объект ValueTask более эффективен, чем объект Task, который может стать причиной упаковки и распаковки.
• По соглашению об именовании методы, которые могут вызываться асинхронно, должны быть помечены с помощью суффикса Async.
Резюме
Глава начиналась с исследования роли пространства имен System.Threading. Как было показано, когда приложение создает дополнительные потоки выполнения, в результате появляется возможность выполнять множество задач (по виду) одновременно. Также было продемонстрировано несколько способов защиты чувствительных к потокам блоков кода, чтобы предотвратить повреждение разделяемых ресурсов.
Затем в главе исследовались новые модели для разработки многопоточных приложений, введенные в .NET 4.0, в частности Task Parallel Library и PLINQ. В завершение главы была раскрыта роль ключевых слов async и await. Вы видели, что эти ключевые слова используются многими типами в библиотеке TPL; однако большинство работ по созданию сложного кода для многопоточной обработки и синхронизации компилятор выполняет самостоятельно.
Часть V
Программирование с использованием сборок .NET Core
Глава 16
Построение и конфигурирование библиотек классов
В большинстве примеров, рассмотренных до сих пор, создавались "автономные" исполняемые приложения, где вся программная логика упаковывалась в единственную сборку (*.dll) и выполнялась с применением dotnet.ехе (или копии dotnet.ехе, носящей имя сборки). Такие сборки использовали в основном библиотеки базовых классов .NET Core. В то время как некоторые простые программы .NET Core могут быть сконструированы с применением только библиотек базовых классов, многократно используемая программная логика нередко изолируется в специальных библиотеках классов (файлах *.dll), которые могут разделяться между приложениями.
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
В настоящей главе вы сначала исследуете детали разнесения типов по пространствам имен .NET Core. После этого вы подробно ознакомитесь с библиотеками классов в .NET Core, выясните разницу между .NET Core и .NET Standard, а также научитесь конфигурировать приложения, публиковать консольные приложения .NET Core и упаковывать свои библиотеки в многократно используемые пакеты NuGet.
Определение специальных пространств имен
Прежде чем погружаться в детали развертывания и конфигурирования библиотек, сначала необходимо узнать, каким образом упаковывать свои специальные типы в пространства имен .NET Core. Вплоть до этого места в книге создавались небольшие тестовые программы, которые задействовали существующие пространства имен из мира .NET Core (в частности System). Однако когда строится крупное приложение со многими типами, возможно, будет удобно группировать связанные типы в специальные пространства имен. В C# такая цель достигается с применением ключевого слова namespace. Явное определение специальных пространств имен становится еще более важным при построении разделяемых сборок, т.к. для использования ваших типов другие разработчики будут нуждаться в ссылке на вашу библиотеку и импортировании специальных пространств имен. Специальные пространства имен также предотвращают конфликты имен, отделяя ваши специальные классы от других специальных классов, которые могут иметь совпадающие имена.
Чтобы исследовать все аспекты непосредственно, начните с создания нового проекта консольного приложения .NET Core под названием CustomNamespaces. Предположим, что требуется разработать коллекцию геометрических классов с именами Square (квадрат), Circle (круг) и Hexagon (шестиугольник). Учитывая сходные между ними черты, было бы желательно сгруппировать их в уникальном пространстве имен MyShapes внутри сборки CustomNamespaces.ехе.
Хотя компилятор C# без проблем воспримет единственный файл кода С#, содержащий множество типов, такой подход может стать проблематичным в командном окружении. Если вы работаете над типом Circle, а ваш коллега — над типом Hexagon, тогда вам придется по очереди работать с монолитным файлом или сталкиваться с трудноразрешимыми (во всяком случае, отнимающими много времени) конфликтами при слиянии изменений.
Более удачный подход предусматривает помещение каждого класса в собственный файл, с определением в каждом из них пространства имен. Чтобы обеспечить упаковку типов в ту же самую логическую группу, просто помещайте заданные определения классов в область действия одного и того же пространства имен:
<b>// Circle.cs</b>
namespace MyShapes
{
// Класс Circle
public class Circle { /* Интересные методы... */ }
}
<b>// Hexagon.cs</b>
namespace MyShapes
{
