Я очень долго ждал минимальную API-инфраструктуру .NET, и вот, наконец, она вышла! Давайте погрузимся в новую версию .NET6 и ответим на следующие вопросы:

  1. Что такое минимальный API .NET?
  2. Как реорганизовать существующий сокращатель URL?
  3. Как добавить зависимость к сервису?
  4. Как добавить конечную точку в сервис?
  5. Где используются операторы?

🤔 1. Введение в .NET Minimal API

"Вам нужно все это только для того, чтобы сократить URL?"

Это была первая реакция друга (который, оказывается, программист на Python), когда я показал ему свой первый пример укорачивания.

«Да» было бы довольно точным ответом, но не тем, которым я был бы доволен.

Было много шаблонного кода по сравнению с другими фреймворками.

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

Большинство поставщиков SaaS используют микросервисную архитектуру из-за ее масштабируемости, меньшего размера/быстрого развертывания и простоты понимания.

Взгляните на шаблон Flask API:

Всего в 5 строках кода у нас есть первая конечная точка! Один файл, никаких других настроек не требуется. Все, на чем нам нужно сосредоточиться, это особенность этого нового сервиса.

Теперь давайте взглянем на исходный шаблон .NET. Из коробки получаем

Startup.cs, Program.cs, Контроллеры… много шаблонного кода. Это может быть ненужным, если цель состоит в том, чтобы написать один небольшой сервис как часть продукта SaaS или просто прототип.

К счастью, .NET6 решает эту проблему. Давайте перепишем предыдущий пример на .NET6 с новым шаблоном.

Всего 4 строки кода для нашей первой конечной точки. Отдельный файл. Это новый минимальный API .NET!

Возвращаясь к вопросу моего друга — «Вам нужны все эти вещи только для того, чтобы сократить URL?»

Нет.
Я могу лучше.

✂️ 2. Рефакторинг примера сокращения URL

Некоторое время назад я написал статью Как написать сокращатель URL в .NET5?, но я никогда не мог представить, что смогу написать сокращатель .NET в 26 строках кода и одном файле.

Примечание: на самом деле у нас есть два файла — мы доберемся до сути в пятом разделе, потерпите меня.

Код рефакторинга:

Вы можете найти предыдущий пример сокращения URL-адресов в этом репозитории github. В кодовой базе нет ничего минимального.

Если мы сравним старый код с нашим минимальным сокращателем, мы сразу увидим скрытую сложность минимального API-фреймворка.

Мы начинаем с нуля в минимальном шаблоне API и вводим только те зависимости, которые нам нужны. Мы можем сосредоточиться на важном — на коде требуемой функции.

Давайте проанализируем код и посмотрим, какие новые возможности появятся в .NET6, что вы могли бы начать реализовывать в своих сервисах.

⚙️ 3. Добавление зависимостей

Моей службе нужна база данных, поэтому я добавляю зависимость к LiteDB.

dotnet add package LiteDB

Обычно мы переходим к Startup.cs и настраиваем нашу зависимость. Поскольку у нас его нет, путь показан ниже в строке 2. Тот же код, но в другом месте.

🔗 4. Добавление конечной точки

Все методы, которые нам нужны, находятся в приложении — или, лучше сказать, в фреймворке?

  • MapGet(шаблон, обработчик)
  • MapPost(шаблон, обработчик)
  • MapPut(шаблон, обработчик)
  • MapDelete(шаблон, обработчик)

Проверьте, как реализовать метод POST и метод GET в приведенном ниже примере.

Первый параметр — это шаблон маршрута, а второй — обработчик. Обработчик делегата выполняется при совпадении конечной точки.

Объект URL — это запись, также что-то новое в .NET6. Это мог быть и класс, но я просто хотел сократить пару строк кода, чтобы получить эти 26 волшебных строк.

Данные, которые должен содержать наш метод POST (тело запроса),
определяются записью. (Достаточно отправить longURL, id будет установлен автоматически нашей db)

У нас есть наша база данных в списке сервисов, которые использует наше приложение. Следующим шагом является внедрение его в конечную точку. Делегат должен иметь контекст нашей базы данных, чтобы добавлять данные от клиента в базу данных.

В конце настройте свой служебный адрес и порт.
Готово!

app.Run("http://localhost:4000");

🙋 5. Где используются утверждения?

Операторы глобального использования — еще одна функция, которой я доволен.

Помните ли вы что-то подобное поверх каждого файла в вашем проекте?

using System;
using System.Reflection;
using System.Linq;
using System.Net.Http;
using System.Linq;

Неявное использование скрыто в автоматически сгенерированном файле внутри папки obj. Этот файл объявляет глобальные операторы using за кулисами. Если вы перейдете в папку проекта, а затем в obj/Debug/net6.0, вы найдете файл с названием "{ProjectName}.GlobalUsings.g.cs".

Откройте этот файл и посмотрите содержимое:

Поскольку это автоматически сгенерированный файл, мы не можем редактировать его здесь.

В нашем минимальном сокращателе у нас есть два пакета (LiteDB, Hashids.net), от которых мы зависим, и нам нужно поместить операторы using в Program.cs, чтобы использовать код. из этих пакетов.

Вместо этого давайте вручную создадим файл, в котором будут храниться наши глобальные операторы using. Таким образом, мы защищаем наш Program.cs от всех операторов использования.

В этом конкретном примере это может быть излишним, но представьте себе добавление дополнительных зависимостей. Это хороший вариант для поддержания чистоты кода.

🎊 Так возможно? Конечно! 🎊

В большинстве случаев нам не нужны все церемонии, которые мы получили с предыдущими шаблонами веб-API .NET.

Теперь есть возможность начать с нуля и добавлять только то, что нам действительно нужно. Отсутствуют контроллеры MVC? Нет проблем, добавьте их позже. Нужна аутентификация? То же самое.

В коде шаблона меньше файлов и более интуитивная настройка для новичков в мире .NET — это, пожалуй, одно из лучших преимуществ этого фреймворка. Я действительно с нетерпением жду возможности увидеть, что принесут будущие обновления.

Если вам понравилось следовать инструкциям и создавать собственный сокращатель URL-адресов в .NET6, следите за этим блогом!

В следующей статье мы разместим это минимальное средство сокращения URL-адресов в Docker и рассмотрим еще одну важную часть технологического стека.