ASP.NET Core. Разработка приложений
Для профессионалов.
Чамберс Джеймс, Пэкетт Дэвид, Тиммс Саймон «ASP.NET Core. Разработка приложений» Питер, 2018 год, 464 стр., ISBN 978-5-496-03071-7; (8,00 мб. pdf)
ASP.NET Core MVC это следующая версия уже знакомого кроссплатформенного фреймворка MVC от компании Microsoft. В ASP.NET Core MVC представлено множество разнообразных библиотек, которые как и сам фреймворк являются продуктом с открытым кодом. Использование ASP.NET Core MVC дает возможность разделить бизнес-логику, маршрутизацию и сервисы, а также предлагает новые методы конфигурирования и работы с расширениями, используя C# и механизм представлений Razor. В этой книге объясняется решение конкретных задач на примере вымышленной компании Alpine Ski House. Каждая глава начинается с краткого изложения проблемы, которая встает перед разработчиками, и того, как они собираются ее решать.
В книге достаточно широко освещена не только функциональность ASP.NET Core MVC, но и рабочий инструментарий, используемый разработчиками для создания, сопровождения и развертывания приложений. Кроме историй и технической информации об ASP.NET Core MVC, в книге рассматривается новая версия Entity Framework, системы управления пакетами и периферийные технологии, используемые современными веб-разработчиками. Вы познакомитесь с архитектурой приложений, средствами развертывания и проектирования приложений для работы в облаке и многими другими технологиями.
Содержание.
ЧАСТЬ I. СПРИНТ ПЕРВЫЙ: ПРИЛОЖЕНИЕ ALPINE SKI HOUSE
Глава 1. Что к чему 25
Active Server Pages 26
ASP.NET 28
ASP.NET MVC 32
Web API 36
ASP.NET Core 38
Итоги 39
Глава 2. Факторы влияния 40
Обратная совместимость 41
Rails 42
Node.js 46
Angular и React 47
Открытый код 49
OWIN 49
Итоги 51
Глава 3. Модели, представления и контроллеры 52
M, V и C 53
Подробнее о моделях 53
Представления 55
Частичные представления 56
Контроллеры (…и действия!) 57
Не только MVC 58
Промежуточное ПО 58
Внедрение зависимостей 60
Другие усовершенствования 61
Итоги 61
Глава 4. Структура проекта 62
Лыжные склоны 64
API 67
Административное представление 68
Все вместе 69
Определение предметной области 70
Итоги 71
Глава 5. Сборка кода 72
Сборка из командной строки 73
Билд-серверы 75
Конвейер сборки 76
Сборка приложения Alpine Ski House 80
Итоги 87
Глава 6. Развертывание 88
Выбор веб-сервера 89
Kestrel 90
Обратный прокси-сервер 91
IIS 92
Nginx 94
Публикация 96
Типы сборок 98
Сборка пакета 100
Несколько слов в пользу Azure 101
Развертывание в Azure 103
Контейнерное развертывание 107
Итоги 107
ЧАСТЬ II. СПРИНТ ВТОРОЙ: ПУТЕШЕСТВИЕ ДЛИНОЙ В 1000 ШАГОВ
Глава 7. Сборка веб-приложений на платформе Microsoft Azure 112
Что такое PaaS 113
Платформенные сервисы 113
Оснастка, уничтожение и воссоздание сервисов 116
Проектирование приложений с использованием Platform Services 117
Создание учетной записи хранения 118
Хранение изображений в BLOB-контейнерах 120
Интеграция очередей хранилища 122
Автоматизация обработки с использованием Azure WebJobs 122
Масштабирование приложений 124
Масштабирование в нескольких направлениях 125
Эластичное масштабирование 126
Другие факторы масштабирования 128
Итоги 129
Глава 9. Контейнеры 144
Повторяемые среды 145
Docker 149
Контейнеры Windows 154
Docker в рабочей среде 156
В облаке 158
Итоги 159
Глава 10. Entity Framework Core 160
Основы Entity Framework 162
Запрос на получение одной записи 164
Запрос на получение нескольких записей 164
Сохранение данных 165
Отслеживание изменений 165
Использование миграции для создания и обновления баз данных 166
Добавление миграций 167
Создание сценариев обновления для рабочих серверов 171
ApplicationDbContext 173
Расширение ApplicationUserContext 174
Контекст для карты 176
Отношения, выходящие за границы контекстов 177
Присоединение контроллера 179
Типы абонементов 185
Абонементы и проверка 187
События и обработчики событий 189
Итоги 191
Глава 11. Представления Razor 192
Создание веб-сайтов с точки зрения современного разработчика 193
Использование предыдущих достижений и находок 194
Роль Razor 194
Основы Razor 195
Взгляд «за кулисы» 195
Выражения в синтаксисе Razor 198
Переключение в режим кода 199
Явное использование разметки 200
Памятка по управлению парсером Razor 200
Использование других возможностей C# 202
Использование типов C# в представлениях 202
Определение модели 202
Использование данных представления 203
Работа с макетами 205
Основы работы с макетами 206
Включение секций из представлений 208
Определение и потребление частичных представлений 209
Использование расширенной функциональности Razor в представлениях 210
Внедрение сервисов в представления 210
Работа с тег-хелперами 212
Предотвращение дублирования в представлениях 216
Использование альтернативных механизмов представлений 217
Итоги 217
Глава 12. Конфигурация и журналирование 219
Расставание с web.config 220
Настройка конфигурации приложения 221
Использование готовых провайдеров конфигурации 223
Построение собственного провайдера конфигурации 224
Применение опций 227
Операции с журналом 228
Создание журналов с доступной информацией 229
Информация об исключениях 230
Журналирование как стратегия разработки 231
Уровни журналирования в ASP.NET Core 232
Применение областей действия 236
Структурированное журналирование 238
Журналирование как сервис 240
Итоги 242
ЧАСТЬ III. СПРИНТ ТРЕТИЙ: В ПАСТИ У ЗВЕРЯ
Глава 13. Идентификация, безопасность и управление правами 246
Эшелонированная оборона 247
Внутренние угрозы 247
Внешние угрозы 249
Оглавление 11
Скрытые данные пользователей 249
Аутентификация с поддержкой Azure 251
Идентификация в ASP.NET Core MVC 257
Учетные записи локальных пользователей 262
Сторонние провайдеры аутентификации 264
Включение средств безопасности с использованием атрибутов 267
Применение политик для авторизации 269
Глобальное применение политик 269
Определение специализированных политик 270
Специальные политики авторизации 271
Защита ресурсов 273
Общий доступ к ресурсам независимо от источника (CORS) 275
Итоги 277
Глава 14. Внедрение зависимостей 278
Что такое «внедрение зависимостей»? 279
Ручное разрешение зависимостей 279
Использование контейнера сервисов для разрешения зависимостей 281
Внедрение зависимостей в ASP.NET Core 282
Использование встроенного контейнера 283
Использование стороннего контейнера 286
Итоги 288
Глава 15. Роль JavaScript 289
Написание хорошего кода JavaScript 290
А это вообще обязательно? 291
Организация кода 292
SPA или не SPA? 293
Сборка JavaScript 294
Bundler & Minifier 295
Grunt 296
gulp 298
WebPack 300
Какой инструмент мне лучше подойдет? 303
TypeScript 304
Компилятор ES2015 в ES5 304
Загрузка модуля 309
Выбор фреймворка 310
Итоги 311
Глава 16. Управление зависимостями 313
NuGet 314
Установка пакетов в NuGet 314
Инструментарий Visual Studio 315
npm 317
Добавление зависимостей 318
Использование модулей npm 318
Интеграция с Visual Studio 319
Yarn 321
bower 323
Добавление зависимостей 324
Обращение к ресурсам из пакетов bower 325
Итоги 325
Глава 17. Стильный интерфейс 327
Создание сайтов с таблицами стилей 328
Немного истории 329
Создание собственной таблицы стилей 331
SASS в работе со стилями 333
Основы SCSS 335
Переменные 335
Импортирование и фрагменты 336
Вложение 337
Создание примесей 339
Объединение примесей и директив 340
Рабочий процесс 341
Инструменты командной строки 341
Работа в Visual Studio Code 341
Изменение задач сборки проекта 342
Использование сторонних фреймворков 343
Расширение фреймворка CSS 343
Настройка используемых элементов фреймворка CSS 344
Применение фреймворков CSS для специализированных таблиц стилей 344
Альтернативы для фреймворков CSS 346
Итоги 347
Глава 18. Кэширование 348
Заголовки управления кэшированием 350
Использование Data-Cache 353
Кэширование памяти 354
Распределенный кэш 355
Ограничение размера кэша 357
Итоги 358
ЧАСТЬ IV. СПРИНТ ЧЕТВЕРТЫЙ: ФИНИШНАЯ ПРЯМАЯ
Глава 19. Многоразовый код 362
Тег-хелперы 363
Оглавление 13
Строение тег-хелперов 363
Тег-хелперы environment, link и script 364
Файловые шаблоны 365
Запрет кэширования 365
Тег-хелпер cache 367
Создание тег-хелперов 367
Работа с существующими атрибутами и содержимым 369
Компоненты представлений 370
Работа с компонентами представлений 372
Что случилось с дочерними действиями? 372
Компонент представления для связи со службой поддержки 372
Частичные представления 374
Итоги 376
Глава 20. Тестирование 377
Модульное тестирование 378
XUnit 378
Основы xUnit 379
Запуск тестов 380
Организация модульного тестирования 382
Тег-хелперы для тестирования 388
Тестирование компонентов представлений 391
Тестирование кода JavaScript 392
Другие виды тестирования 397
Итоги 398
Глава 21. Расширение фреймворка 399
Соглашения 400
Создание нестандартных соглашений 401
Промежуточное ПО 403
Настройка конвейера 403
Написание промежуточного ПО 405
Разветвление конвейера 407
Загрузка внешних контроллеров и представлений 408
Загрузка представлений из внешних проектов 409
Загрузка контроллеров из внешних сборок 409
Маршрутизация 410
Маршрутизация на основе атрибутов 411
Расширенная маршрутизация 412
Инструменты dotnet 412
Изоморфные приложения и сервисы JavaScript 413
Изоморфные приложения 413
Использование Node 414
Итоги 415
Глава 22. Интернационализация 416
Локализация текста 419
Локализация строк 419
Создание файлов ресурсов 421
Локализация представлений 422
Аннотации данных 423
Совместное использование файлов ресурсов 423
Назначение текущей культуры 424
Итоги 428
Глава 23. Рефакторинг и повышение качества кода 429
Что такое рефакторинг? 430
Оценка качества кода 432
Выбор времени для рефакторинга 434
Меры безопасности при рефакторинге 434
Разработка на основе данных 442
Пример чистки кода 443
Полезные инструменты 448
На пути к качественному коду 448
Итоги 448
Глава 24. Организация кода 450
Структура репозитория 451
Внутри исходного кода 452
Параллельная структура 452
Паттерн «Посредник» 454
Краткое введение в паттерн «Передача сообщений» 454
Реализация паттерна «Посредник» 455
Области 459
Итоги 460
Послесловие 461
Об авторах 464
Книга «ASP.NET Core. Разработка приложений»
Современные разработчики занимаются построением кроссплатформенных приложений, их сопровождением и развертыванием. Чтобы облегчить им тяжкий труд, был создан новый фреймворк компании Microsoft — ASP.NET Core. Теперь в вашем распоряжении множество разнообразных библиотек с открытым кодом, более того, сам фреймворк является продуктом с открытым кодом.
Как же освоить все новые возможности, предоставляемые ASP.NET Core? Авторы объясняют решение конкретных задач на примере вымышленной компании Alpine Ski House. Каждую главу предваряет краткий рассказ о проблеме, с которой сталкивается команда разработчиков, и о том, как они эту проблему преодолевают. Вам предстоит познакомиться с архитектурой приложений, средствами развертывания и проектирования приложений для работы в облаке и многим другим.
В этой книге рассматриваются первые спринты разработки приложения в вымышленной компании Alpine Ski House. Каждую главу предваряет краткий рассказ о проблеме, с которой сталкивается команда разработчиков, и о том, как они собираются ее преодолевать. Несмотря на присутствие элемента вымысла, в книге достаточно глубоко освещена не только функциональность ASP.NET Core MVC, но и инструментарий, используемый разработчиками для построения, сопровождения и развертывания приложений.
Кроме историй и технической информации об ASP.NET Core MVC, в книге рассматривается новая версия Entity Framework, системы управления пакетами и периферийные технологии, используемые современными веб-разработчиками. Помимо теоретического учебного материала, к книге также прилагается сопроводительный проект — тот самый, который разрабатывают программисты из Alpine Ski House.
Для кого написана эта книга
Книга проведет программиста по всем этапам создания нового приложения на базе ASP.NET Core и обеспечения доступа к нему через интернет. Многие программисты все еще далеки от мира веб-разработки или лишь незначительно соприкоснулись с ним посредством WebForms, несмотря на широкий спектр доступных в настоящее время программных инструментов. Книга поможет читателю овладеть навыками, необходимыми для проектирования современных приложений на активно развивающемся фреймворке. Вы изучите архитектуру приложений, средства развертывания и проектирования приложений для работы в облаке.
Эта книга вам не подойдет, если…
Эта книга может вам не подойти, если вы — опытный разработчик ASP.NET MVC, внимательно следивший за ходом разработки ASP.NET Core MVC или принимавший в нем непосредственное участие.
Структура книги
В книге используется необычный подход: она проводит разработчиков по отдельным спринтам в ходе разработки приложения. Рассматривается не только технология, но также процесс восстановления после ошибок и реакция разработчиков на обратную связь от пользователей. Мы начнем с пустого листа и закончим полноценным работоспособным продуктом.
Книга поделена на четыре части:
• Часть I «Спринт первый: Приложение Alpine Ski House» вводит читателя в суть ситуации: в ней описывается приложение, используемое в книге, и вымышленные персонажи истории.
• Часть II «Спринт второй: Путешествие длиной в 1000 шагов» посвящена основным функциональным аспектам приложения и настройке конвейера, с помощью которого развертывание станет происходить «на лету», а процесс будет понятным для всей команды разработки.
• Часть III «Спринт третий: В пасти у зверя», уделяет основное внимание базовой функциональности, необходимой для того, чтобы начать использовать тестовое приложение в реальных бизнес-процессах. В частности, здесь рассматривается работа с данными посредством Entity Framework Core, созданиепредставлений на базе Razor, настройка конфигурации и журналирование, безопасность и управление правами, и наконец, внедрение зависимостей.
• Часть IV «Спринт четвертый: Финишная прямая» описывает JavaScript и управление зависимостями, а также развивает некоторые предыдущие темы.
В конце книги рассматриваются такие важные темы, как тестирование, рефакторинг и добавление расширений.
Отрывок. Рефакторинг и повышение качества кода
Мало кто из разработчиков доволен кодом, который они написали год назад. Расхожая шутка на многих семинарах по программированию: программист восклицает «Кто написал этот мусор?», заглядывает в историю и выясняет, что это был он. На самом деле это замечательная возможность. Приступая к написанию кода, часто вы только пытаетесь разобраться в предметной области, задаче программирования и структуре приложения, которое вам предстоит написать. Объем информации, которую разум может усвоить за один раз, ограничен, а большое количество «подвижных частей» часто приводит к ошибкам в структуре или функциональности кода. Вернуться и исправить старый код спустя несколько месяцев, когда ваше понимание приложения улучшилось, — величайшая роскошь.
В этой главе рассматривается идея рефакторинга и возможности усовершенствований функциональности приложения без нарушения его работоспособности.
Что такое рефакторинг?
Термин «рефакторинг» был предложен в начале 1990-х годов Уильямом Опдайком (William Opdyke) и Ральфом Джонсоном (Ralph Johnson). Да, есть книга, написанная «Бандой четырех»1. Под рефакторингом понимается изменение внутренней структуры блока кода, в результате которого код становится более понятным, удобным в тестировании, лучше адаптируется к изменениям, причем его внешняя функциональность не изменяется. Если представить себе функцию в виде «черного ящика», который получает входные данные и выдает выходные данные, изменение внутренней структуры «черного ящика» особой роли не играет, если ввод и вывод остаются неизменными (рис. 23.1).
Это наблюдение позволяет вам заменять код в приложении с сохранением функциональности и повышением общего качества приложения. И хотя мы используем термин «функция» как обозначение блока кода, его область действия не обязана ограничиваться внутренним строением функции. Вся суть объектно-ориентированного программирования — широкое введение абстракций для защиты от раскрытия подробностей реализации. Есть много конструкций, которые могут рассматриваться как «черный ящик» для целей рефакторинга. Первым кандидатом становятся классы. Реализация класса несущественна, если входные и выходные данные остаются неизменными, поэтому мы можем изменять его внутренние механизмы так, как считаем нужным. Пространства имен не обеспечивают тот же уровень защиты, что и классы, но также могут рассматриваться как кандидаты на замену. Наконец, в мире микросервисов все приложение может быть заменено другим приложением, и такая замена тоже станет частью рефакторинга.
Рассмотрим сервис, обязанностью которого является отправка электронной почты по списку рассылки. Вводом может быть список получателей и отправляемое сообщение. Место вывода как такового здесь занимает результат: получение сообщения всеми адресатами из списка получателей (рис. 23.2).
Неважно, как именно микросервис рассылает сообщения: с помощью Sendgrid или с собственного сервера. В любом случае результат остается одним и тем же. В данном случае замена микросервиса может считаться рефакторингом.
Программисты обычно называют рефакторингом все, что способствует улучшению кода. Исключили лишний параметр метода? Добавили запись в журнал в коварном методе, чтобы обеспечить улучшенную поддержку DevOps? Хотя качество кода или качество приложения в обоих случаях повышается, ни один из них формально не может рассматриваться как рефакторинг, потому что они изменяют функциональность приложения. Полное следование определению рефакторинга требует, чтобы неизменным оставался как ввод (в том числе и состав параметров), так и вывод (включая сообщения в журнале).
Оценка качества кода
Если разработчик занимается рефакторингом для повышения качества кода, безусловно, должен существовать некоторый критерий оценки качества кода. Было бы замечательно иметь инструмент для оценки качества кода — безукоризненную метрику, способную представить все аспекты качества кода одним числом. К сожалению, такой метрики не существует. За прошедшие годы предлагалось бесчисленное множество метрик качества, от центробежного и центростремительного сцепления до оценки количества ошибок в строке кода и степени тестового покрытия кода. Выбор набора метрик качества кода — тема, которая сама по себе заслужила бы целой книги.
Впрочем, будет полезно выделить несколько простых метрик для оценки качества кода:
• Делает ли код то, что ему положено делать? На первый взгляд очевидно, но об этой метрике часто забывают. Ее можно оценить по количеству заявленных ошибок на тысячу строк кода или по количеству ошибок на класс. Некоторые разработчики используют эту метрику глобально, сравнивая относительное качество двух проектов по количеству обнаруженных дефектов. Впрочем, такой подход непродуктивен, потому что два проекта никогда не решают одну проблему. Можно ли ожидать, что система создания и доставки электронных поздравительных открыток будет иметь такую же степень сложности или количество ошибок, что и система управления дозатором инсулина? Нет, конечно. Эта метрика, как и большинство других, просто помогает узнать, совершенствуется ли группа и продукт со временем.
• Удовлетворяет ли код своим нефункциональным требованиям? Речь идет о требованиях, не связанных с вводом или выводом функции (как, например, производительность фрагмента кода или его защищенность).
• Насколько понятен код? Идеального кода вообще не бывает, и кому-то рано или поздно понадобится обновить его из-за обнаруженной ошибки или изменившихся требований. Этим «кем-то» может стать даже автор кода, то есть вы! Взгляните на следующий фрагмент:
Возможно, это эффективный и умный код, но разобраться в нем почти невозможно. Найти объективную метрику понятности или удобочитаемости достаточно сложно. Эта метрика — не столько число, сколько воплощение согласованного мнения разработчиков относительно удобства сопровождения. В группах нормальных людей, не отягощенных амбициями, редко возникают серьезные расхождения по поводу того, насколько хорошо читается код. Рецензирование кода — прекрасный инструмент для обнаружения непонятных участков кода.
Другая простая, но практичная метрика — цикломатическая сложность — оценивает сложность функций по количеству ветвей кода в методе. Метод с одной командой if содержит две возможные ветви кода, а значит, его цикломатическая сложность равна 2 (рис. 23.3).
• Способен ли код легко реагировать на изменения в требованиях? И снова эта метрика не может быть выражена простым числом. Скорее это ощущение, возникающее в группе опытных разработчиков. По кислому выражению на лице разработчика, когда в его коде предполагаются серьезные изменения, можно с уверенностью определить, достигнута ли эта цель.
Эти четыре простые метрики станут хорошей отправной точкой для принятия решения о том, каким частям приложения может понадобиться рефакторинг. Вероятно, в процессе роста и развития приложения вам удастся обнаружить и добавить новые метрики.
Когда в вашем распоряжении оказывается несколько метрик, важно убедиться в том, что приложение не оптимизируется по ошибочной метрике. Люди склонны обманывать систему, сознательно или нет. Если выбрать метрику производительности, обеспечивающую максимально быстрый возврат из функции, но при этом не добавить метрику, устанавливающую разумное ограничение затрат памяти, появляется искушение оптимизировать функцию так, чтобы она расходовала память в обмен на вычислительные ресурсы. Подумайте, действительно ли это именно то, что вам нужно, или на самом деле конечной целью является баланс. Проанализируйте метрики и убедитесь в том, что оптимизация не идет в неверном направлении, а если все же идет — обновите набор метрик.
Об авторах
Джеймс Чамберс, пятикратный обладатель статуса Microsoft MVP в области технологий разработки, в настоящее время занимается разработкой с использованием ASP.NET Core и MVC Framework на платформе Azure и AWS. Он является независимым консультантом, преподавателем и активным блоггером, а также участником ряда проектов с открытым кодом.
Саймон Тиммс, обладатель статуса Microsoft MVP на протяжении многих лет — организатор сообществ, блоггер, разработчик и независимый консультант. Его технологические интересы весьма разнообразны, он увлекается всем — от распределенных систем до новомодных фреймворков JavaScript. Обладая хорошей подготовкой как в области разработки, так и в организации текущей работы, он нередко сводит с ума свои группы, участвуя во всех этапах, от построения и разработки до обслуживания серверов.