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

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

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

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

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

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


      Существует несколько причин для создания суперпростых и легких 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/

      КОММЕНТАРИИ И ОБСУЖДЕНИЯ

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

      Стартовый
      • Все видеокурсы на 3 месяца
      • Тестирование по 10 курсам
      • Проверка 5 домашних заданий
      • Консультация с тренером 30 мин
      Базовый
      • Все видеокурсы на 6 месяцев
      • Тестирование по 16 курсам
      • Проверка 10 домашних заданий
      • Консультация с тренером 60 мин
      Премиум
      • Все видеокурсы на 1 год
      • Тестирование по 24 курсам
      • Проверка 20 домашних заданий
      • Консультация с тренером 120 мин
      new
      Премиум Plus
      • Все видеокурсы на 1 год
      • Тестирование по 24 курсам
      • Проверка 20 домашних заданий
      • Консультация с тренером 120 мин
      • Скачивание видео уроков
      Notification success
      Мы используем cookie-файлы, чтобы сделать взаимодействие с нашими веб-сайтами и услугами простым и значимым.