API Endpoints как Замена Контроллерам MVC
Контроллеры в MVC по сути являются антипаттерном. Это наборы методов, которые никогда не вызывают друг друга и редко работают с одним и тем же состоянием. Они не связаны, имеют тенденцию раздуваться и выходить из-под контроля. Их приватные методы, если они вообще есть, обычно вызываются только одним публичным методом. Большинство разработчиков признают, что контроллеры должны быть как можно тоньше, но это единственное решение, предлагаемое «из коробки», так что это инструмент, который используют 99% разработчиков ASP.NET Core.
Вы можете использовать такие инструменты, как MediatR, чтобы смягчить проблему. MediatR позволяет использовать однострочные методы действий, которые направляют команды обработчикам. Но что, если можно обойтись и без этой надстройки?
Зачем использовать нестандартный фреймворк?
API Endpoints - это на самом деле просто контроллеры с наложенными на них некоторыми ограничениями. Они наследуют от
ControllerBase. Таким образом, они ни в коем случае не являются нестандартным подходом, и всё, что работает с контроллерами (маршрутизация, привязка модели, проверка модели, внедрение зависимостей, фильтры и т.д.), отлично работает с API Endpoints.Вы, конечно, можете сами создавать контроллеры, соответствующие принципу SRP, но давайте честно, вы не будете этого делать. Например, практически все согласны с тем, что прямое изменение глобального состояния из множества различных функций, классов и модулей - плохая практика. Поэтому большинство языков предлагают области видимости для локальных переменных и аргументов, а большинство ОО-языков предлагают множество способов защиты и инкапсуляции переменных с использованием таких ключевых слов, как private, protected и internal. «Но нам не нужны эти ограничения - мы можем просто использовать соглашение об именах для наших глобальных переменных, чтобы сделать то же самое!» Да, да… Дайте знать, когда это заработает.
Хорошо, как начать работать с API Endpoints?
Для начала прочитайте файл README этого репозитория. В репозитории также есть образец проекта, который вы можете просмотреть, чтобы увидеть, как использовать паттерн Request-EndPoint-Response (REPR). Другие проекты с этим подходом: шаблон Clean Architecture и справочное приложение eShopOnWeb от Microsoft.
Если у вас уже есть проект и вы просто хотите начать использовать API Endpoints вместо контроллеров, просто добавьте пакет NuGet Ardalis.ApiEndpoints, а затем создавайте конечные точки, наследуя от типов
BaseEndpoint или BaseAsyncEndpoint.Паттерн REPR
Model-View-Controller (MVC) предназначен для работы с пользовательскими интерфейсами. Если вы создаёте API, представлений нет, поэтому в лучшем случае вы используете паттерн MC или его можно назвать Model-Action-Controller. То есть вы уже не используете MVC для API, поэтому можно подумать о более подходящем паттерне.
Конечные точки в API довольно самодостаточны, и каждую из них можно описать с помощью трёх компонентов:
1. Запрос - данные, ожидаемые конечной точкой.
2. Конечная точка - логика, которую конечная точка выполняет при получении запроса.
3. Ответ - ответ, который конечная точка возвращает вызывающей стороне.
Так получается паттерн Request-EndPoint-Response или REPR.
Не всем конечным точкам требуются данные в запросе или ответе. Но пустой запрос или ответ допустим, так же как некоторые действия MVC не требуют модели.
Использование библиотеки API Endpoints позволяет сгруппировать классы запроса, конечной точки и ответа в одном месте, чтобы вам не приходилось копаться в папках типа
ViewModels или DTOs в поисках нужного класса. Библиотека значительно упрощает работу с отдельными конечными точками.Источник: https://ardalis.com/mvc-controllers-are-dinosaurs-embrace-api-endpoints/