Andriy Shyrokoryadov
.Net developer, data scientist
.Net developer, data scientist
Приветствую Вас на моём канале. Данное видео будет первым конкретным видео на тему ASP.NET Core. Ранее я уже снял вводное видео на эту тему, однако на тот момент я еще не определился какие вопросы и в какой форме они буду затронуты в данной серии видео. Сегодня у меня уже есть определенное видение как тематика приложений ASP.NET Core будет представлена на моём канале.
Первым делом нам необходимо ответить на вопрос из каких элементов или концепций, так сказать, строительных блоков состоит приложение ASP.NET Core. Таких блоков несколько. В данном видео мы пройдемся по каждому элементу быстро, оговорим лишь основное назначение конкретного элемента. А в последующих видео в серии мы обговорим каждый элемент более детально.
В данный момент для примеров я буду использовать Visual Studio 2019 и фреймворк .Net 5.0, который является самым актуальным на момент съемки данного видео. Итак, когда мы создаем новый пустой проект Asp.Net Core в Visual Studio, фактически мы не получаем пустой проект. В ново добавленном проекте уже есть некоторые файлы. Давайте с ними ознакомимся. Давайте посмотрим на файл Program.cs – данный файл напоминает аналогичный файл в консольном приложении. Например, в данном файле есть метод Main, который принимает несколько аргументов типа string. В отличие от обычного консольного приложения в методе Main уже добавлен определенный код – вызов метода CreateHostBuilder в который передаются аргументы, с которыми был вызван метод Main. Познакомимся с имплементацией метода CreateHostBuilder – много новых названий среди которых можно разобрать название класса Startup. Именно этот класс нам и нужен, чтобы произвести первоначальную конфигурацию приложения ASP.NET Core. Класс Startup, который был автоматически добавлен, в наше «пустое» приложение является одним из первым элементов приложения ASP.NET Core с которым мы познакомимся.
Класс Startup изначально имеет 2 публичных метода:
метод ConfigureServices служит для настройки услуг, которые будут использоваться нашим приложением. Например, в данном методе можно указать параметры соединения с базой данных, которую будет использовать наше приложение. Однако по умолчанию этот метод пуст и наличие тела метода не является обязательным. С пустым методом ConfigureServices наше приложение может также работать.
метод Configure используется для определения какие связующие программные компоненты (middleware) и для какой среды (environment) будут использоваться в данном приложении ASP.NET Core. В данный метод по умолчанию добавляется определенный код. Я подозреваю, что это связующие программные компоненты, без которых приложение ASP.NET Core не в состоянии нормально функционировать. Как вы, наверное, догадались связующие программные компоненты (middleware) и среда приложения (environment) — являются также, как и класс Startup, неотъемлемыми элементами приложения ASP.NET Core.
Прежде чем мы познакомимся с этими 2 элементами, я хотел бы сказать пару слов об одном очень важном элементе приложения ASP.NET Core и не только. Элемент, который я сейчас вам представлю, важен и для других типов приложений в среде .Net, однако именно в приложениях ASP.NET Core этому элементу уделено особое внимание и его использование почти что обязательное. Речь идет о внедрении зависимости. О данной концепции будет снято отдельное видео на канале в более широком контексте, не только связанным с ASP.NET Core, но и с другими типами приложений.
Ну а пока очень короткое объяснение концепции внедрения зависимости на пальцах. У вас есть некоторый интерфейс А, который реализуется классом В. Код вашего приложения зависит от интерфейса А, например в классах D, E, F конструктор принимает аргумент типа интерфейс А. Вы хотели бы, чтобы везде, где у нас есть зависимость от интерфейса А, использовался класс В, который реализует этот интерфейс. То есть, когда вы будет создавать объекты классов D, E, F, в их конструкторы будет автоматически передаваться объект класса В, который реализует интерфейс А. То есть, можно сказать, что вы зарегистрировали зависимость интерфейса А в виде реализации класса В. Что это нам дает? Предположим, программисты добавили новую имплементацию интерфейса А – класс С. Мы меняем регистрацию зависимости интерфейса А с класса В на класс С только лишь в одном месте. А в результате при создании объектов классов D, E, F они будут получать уже класс С. То есть в коде будет мало изменений. Меньше изменений – меньше ошибок. Именно поэтому важно, чтобы наш код зависел от абстракций (интерфейсов и абстрактных классов), как гласит принцип D SOLID. На этом принципе основана концепция внедрения зависимостей.
Возвращаясь к приложениям ASP.NET Core, то зависимости регистрируются в методе ConfigureServices. Иногда зависимости называют услугами и, в связи с этим метод ConfigureServices очень даже подходит для этого задания.
Уже ранее упоминалось, что взаимодействие с приложением ASP.NET Core осуществляется, через запросы HTTP. Однако прежде, чем запрос дойдет до своего адресата – контроллера в приложении ASP.NET Core, он должен пройти через последовательность определенных компонентов в приложении, которые называются связующими программными компонентами (middleware). Каждый запрос HTTP имеет в своей структуре объект HttpContext и связующие программные компоненты работают с этим объектом. В результате данной работы запрос HTTP с объектом HttpContext либо передаётся в следующий связующий компонент по цепочке вплоть до контроллера, либо запрос возвращается отправителю. ASP.NET Core имеет достаточно большое количество встроенных связующих программных компонентов, а также можно создавать свои собственные связующие программные компоненты. Какие функции выполняют данные связующие компоненты. Самые различные. Например, можно проверить авторизирован ли пользователь для выполнения данного запроса – если да, то запрос будет переда дальше в следующий компонент; если нет – то запрос будет возвращен с ошибкой отправителю.
Следующим элементом приложения ASP.NET Core является главный узел или хост. Хост включает в себя все ресурсы, которые необходимы для работы приложения ASP.NET Core. К данным ресурсам можно отнести:
Существуют 2 типа хостов:
В 99% случаев вы будете использовать обобщённый хост .NET, потому что второй тип хоста был добавлен только лишь для обратной совместимости приложения ASP.NET Core. Если мы еще раз посмотрим на файл Program.cs, то увидим в методе CreateHostBuilder, что мы создаем хост с конфигурацией по молчанию, т. е. используем опцию ConfigureWebHostDefaults. О данной конфигурации мы поговорим более подробно в одном из последующих видео.
Сервер – это следующий компонент приложения ASP.NET Core. В зависимости от платформы, которая будет использована для работы нашего приложения, у нас есть различные варианты выбора. Для всех платформ, т. е. для Windows, Mac и Linux у нас доступен сервер Kestrel. Сервер Kestrel – это кроссплатформенный веб-сервер. Для платформы Windows у нас есть еще 2 варианта серверов для приложения ASP.NET Core – это сервер IIS HTTP (Internet Information Service) и сервер HTTP.sys – веб сервер Windows не связанный с IIS.
Чтобы наше приложение ASP.NET Core правильно работало, нам необходимо настроить его соответствующим образом. Конфигурация приложения является следующим строительным блоком приложения ASP.NET Core. В ASP.NET Core существует фреймворк, который создаёт конфигурационные опции в виде пар «ключ-значение» из данных полученных с помощью различных поставщиков конфигураций или на английском – ConfigurationProvider. Встроенные поставщики конфигураций поддерживают чтение данных из файлов json и xml, из переменных среды и переменных переданных в виде аргументов командной строки. Также для удобства работы с конфигурацией используется шаблон проектирования «Опция».
Приложение ASP.NET Core поддерживает 3 среды: разработка (development), тестирование (staging), производство (production). Текущая среда определяется значением переменной среды ASPNETCORE_ENVIRONMENT. Данная переменная вчитывается при загрузке приложения и хранится в объекте IWebHostEnvironment. Данный объект передается в качестве аргумента в метод Configure о котором мы упоминали в начале при рассмотрении файла Startup. Как вы видите в зависимости от среды мы определяем стоит ли нам использовать страницу с ошибками для разработчиков, то есть страницу, где отображается детальная информация об ошибках.
Информация о работе приложения ASP.NET Core может быть получена посредством логирования. Существуют различные поставщики услуги логирования в ASP.NET Core – здесь могут использоваться как встроенные фреймворки логирования в ASP.NET Core, так и фреймворки, созданные сторонними компаниями. Среди доступных фреймворков и поставщиков можно выделить следующие:
Обслуживание ошибок в ASP.NET Core может быть реализовано при помощи одного из следующих элементов:
Маршрутизация ASP.NET Core заключается в том, чтобы каждый запрос HTTP к приложению ASP.NET Core отправить к соответствующим контроллеру и методу контролдера. Данный компонент приложения ASP.NET Core отвечает за то, чтобы правильно определить, какой контроллер отвечает за обслуживание запроса данного типа, и направление запроса к найденному контроллеру.
Для выполнения запросов к приложению ASP.NET Core нам необходим клиент HTTP. Данный клиент мы можем получить, используя одну из реализаций интерфейса IHttpClientFactory. Как мы видим, разработчики ASP.NET Core использовали шаблон проектирования «фабрика».
В данном видео мы бегло познакомились с основными строительными блоками приложения ASP.NET Core. В последующих видео я планирую более подробно остановиться на каждом из них. Я постараюсь снять видео не очень длинными, однако если видео на какую-то конкретную тему ASP.NET Core получится коротким, то я объеденю пару или несколько тем в одно видео. Мне нет смысла выпускать раз в неделю видео длинной пару минут, да и зрителям это может показаться не интересно.
Спасибо за внимание и до новых встреч в следующих видео. Не забываем ставить лайки и подписываться на канал – это очень помогает в продвижении канала и повышает мою заинтересованности в выпуске новых видео.