Построение микросервисов на ASP.NET Core (без MVC) - Блог ITVDN
ITVDN: курсы программирования
Видеокурсы по
программированию

Выбери свою IT специальность

Начать бесплатно

Выбери свою IT специальность

Начать бесплатно

Построение микросервисов на ASP.NET Core (без MVC)

LIVE ONLINE FRONTEND DEVELOPER Live Online Java

Существует несколько причин для создания суперпростых и легких HTTP сервисов, которые еще называются «микросервисами». Нет нужды говорить обо всех операционных и архитектурных преимуществах такого подхода к построению системы, так как это не раз обсуждалось на разных ресурсах.

Я хотел бы показать пару техник построения весьма простых и компактных HTTP сервисов на основе ASP.NET Core без использования каких-либо фреймворков и с минимальным разрастанием кода.

Предпосылки

То, что я буду обсуждать в данной статье, базируется на пакете ASP.NET Core 1.2, который на момент написания еще не был в релизе.

Я использую CI, поданную в ASP.NET Core, поэтому мой Nuget.config выглядит таким образом:

Когда версия 1.2 добавится в Nuget, этого больше не потребуется.

ASP.NET HTTP endpoints без MVC

ASP.NET Core позволяет определить HTTP endpoints непосредственно на спецификации OWIN, которая построена вокруг, не используя полномасштабную структуру MVC и ее контроллеры для обработки входящих запросов. Так было с самого начала – вы могли использовать компоненты промежуточного программного обеспечения для обработки входящих HTTP запросов и короткую схему ответа непосредственно клиенту. Во многих проектах на основе профиля ASP.NET Core уже используется такая техника, например, Identity Server 4. 

Это не новая концепция – нечто подобное существовало (хотя и в ограниченной форме) в классическом ASP.NET с HTTP модулями и HTTP обработчиками. Позднее, в Web API можно было определить обработчики сообщений для обработки HTTP запросов без необходимости определения контроллеров. И, наконец, в OWIN и в Project Katana это также было возможно через подключение к пользовательским компонентам промежуточного ПО.

Другой альтернативой является точное определение пользовательского IRouter и прикрепление от него различных endpoints. Основное различие между этим подходом и подключением пользовательских компонентов промежуточного ПО в том, что маршрутизация сама по себе представляет единое промежуточное ПО. Это также дает нам возможность для гораздо более сложного сопоставления URL шаблона и определения ограничения маршрута – то, что Вам нужно было бы обрабатывать вручную в случае промежуточного программного обеспечения.

ASP.NET Core 1.2 скоро представит ряд новых методов расширения на IRouter, которые сделают создание простых и компактных HTTP endpoints еще проще. Станет возможным заполнить более ранние версии ASP.NET Core этой функциональностью путем простого копирования новых расширений в ваш проект.

Настройка базы для простого и компактного HTTP API

Это project.json для нашего микросервиса. Он содержит только самые базовые пакеты.

Мы используем здесь абсолютный минимум:

• Kestrel и IIS интеграция выступают в качестве хоста сервера

• пакет маршрутизации

• пакеты протоколирования и конфигурации

Для того, чтобы привести и наш код к абсолютному минимуму, мы можем даже бросить концепцию Startup класса для нашей API установки, и просто писать весь код бэкэнда API в одном файле. Вместо того, чтобы закреплять все в типичные Startup точки расширения, такие как методы Configure() и ConfigureServices(), мы повесим все на WebHostBuilder.

WebHostBuilder довольно часто игнорируется разработчиками ASP.NET Core, потому что генерируется шаблоном в качестве точки входа внутри класса Program, и, как правило, нам не нужно даже изменять его – поскольку он по умолчанию указывает на класс Startup, где происходит почти вся работа по настройке и конфигурации. Тем не менее, он также предоставляет аналогичные зацепки, которые есть у Startup, поэтому можно просто определить все непосредственно на WebHostBuilder.

Наша базовая API конфигурация приведена ниже. Она еще ничего не делает с точки зрения воздействия HTTP endpoints, но она полностью функциональна со стороны процесса подготовки создания (маршрутизатор подключен), входа в консоль и захвата конфигурации из JSON и переменных окружения.

Мне нравится этот подход, поскольку он поразительно краток. Примерно в 20 строках кода мы имеем отличную базу для легкого HTTP API. Естественно, мы могли бы обогатить ее более широкими возможностями по необходимости – например, добавить в наши собственные сервисы или добавить проверку маркера с использованием соответствующих пакетов интеграции из Microsoft.Security или IdetntityServer4.

Добавление HTTP endpoints в наше решение

Финальный шаг – это добавление HTTP endpoints. Мы сделаем это, используя вышеупомянутый расширяющий метод, который будет представлен в ASP.NET Core 1.2. Для демонстрации нам необходима любая модель и сымитированные данные, чтобы использовать стандартный Contact и примеры ContactRepository.

Код ниже запускается в расширяющем методе Configure() на WebHostBuilder, о чем уже было упомянуто ранее. Он показывает HTTP обработчики для получения всех контактов и получения контакта по ID.

Этот код должен быть достаточно самостоятельным в описании – мы делегируем справочную операцию в хранилище и затем просто выводим результат в HTTP ответе. Расширяющий метод-маршрутизатор также дает нам доступ к значениям данных маршрута, делая простым управление сложных URI. К тому же, мы можем использовать обычные шаблоны маршрутов ASP.NET Core со всей мощью ограничений, которые очень удобны, например, так как вы и ожидаете, contacts/{id:int} не будут поставлены в соответствие для нецелочисленных ID.

Я также помог себе, добавив удобный расширяющий метод для написания ответного потока.

Финальный шаг – это добавление в HTTP endpoints изменения состояния серверной части:

  • POST (добавить) новый контакт
  • PUT контакт (изменить существующий)
  • DELETE (удалить) контакт

Нам потребуется дополнительный расширяющий метод, чтобы упростить это, потому что необходимо дессерилизовать запрос тела потока в JSON и нам хотелось бы проверить аннотацию данных нашей модели, чтобы гарантировать, что запрос от клиента является валидным. Очевидно, что будет глупо повторять код раз за разом.

Этот расширяющий метод приведен ниже и в нем используются JSON.NET и System.ComponentModel.DataAnnotations.Validator.

Заметьте, что метод вернет клиенту ‘400 Bad Request’, если модель не окажется валидной. Например, требуемое поле будет пропущено – мы также получим ошибку валидации.

Далее показано определение HTTP endpoints:

Вот и все – вы можете улучшить этот код, добавив в него, например, удобные методы чтения и выбора значений из RouteDataDictionary. Также не вызовет проблем усиление кода аутентификацией и даже внедрение в него новой авторизационной политики ASP.NET Core.

Полный код нашего «микросервиса» (без вспомогательных расширяющих методов, которые, я предполагаю, вы в любом случае захотите собрать воедино и заново использовать) показан ниже – и мне нравится полученный результат. Я считаю, что это весьма привлекательный, лаконичный способ построения простого и компактного API в ASP.NET Core.

Исходники доступны на Github.

Оригинал статьи тут: http://www.strathweb.com/2017/01/building-microservices-with-asp-net-core-without-mvc/

КОММЕНТАРИИ И ОБСУЖДЕНИЯ
LIVE ONLINE FRONTEND DEVELOPER Live Online Java

Пакеты подписки с доступом ко всем курсам и сервисам

Стартовый
  • Все видеокурсы на 3 месяца
  • Тестирование по 10 курсам
  • Проверка 5 домашних заданий
  • Консультация с тренером 30 мин
Базовый
  • Все видеокурсы на 6 месяцев
  • Тестирование по 16 курсам
  • Проверка 10 домашних заданий
  • Консультация с тренером 60 мин
Премиум
  • Все видеокурсы на 12 месяцев
  • Тестирование по 24 курсам
  • Проверка 20 домашних заданий
  • Консультация с тренером 120 мин
Notification success