ASP.NET Core - фреймворк от Microsoft для разработки веб приложений. В том числе для разработки REST Api. В 2017 вышел .net core 2.0 и это была бомба - язык на котором ты писал всю жизнь теперь стал востребованным x2. Больше нет ограничений в виде Windows Server или IIS. Теперь можно спокойно все развернуть в пару кликов на Centos или Ubuntu и в качестве балансера использовать NGINX. В дальнейшем запихнуть все в докер, а докер развернуть в k8s. Спасибо Microsoft.
Переходя к теме статьи - немногие даже опытные эксперты (субъективное мнение) заметили, что за 5 лет от .net core 2.0 до .net6.0 помимо названия фреймворка поменялось кое что еще.
Как было раньше
Проект для ASP.NET Core Api в .net core 2.0 и .net core 3.1 выглядит примерно так - точка входа, встроенный DI-контейнер и папка с контролерами в которых описываются методы REST Api.
Бизнес логику можно описывать прямо в методах, но с точки зрения чистой архитектуры лучше их выносить в отдельные модули (в рамках концепции .net правильнее говорить сервисы) и внедрять их через конструктор.
FYI внедряемые сервисы должны быть зарегистрированы во встроенном DI-container.
Идем дальше
Теперь начиная с .net6.0 (может и раньше) внедрять зависимости можно напрямую в методы. Возможно сейчас это выглядит как не особо полезная фича, но как минимум больше нет необходимости создавать private readonly переменные и описывать конструктор.
Ради чего все это ?
Почему проще некуда ?
Теперь вообще можно удалить папку Controllers не создавать отдельные классы под каждую группу методов, а просто описать все прямо в классе Startup и выглядит это так
Проще некуда же ?
Вывод
Данная статья не является призывом к действию и у меня не было цели показать как правильно. Понятное дело, что удобнее роуты раскладывать по группам (Controllers), но например для маленького проекта... почему нет ? Зачем плодить лишние/ненужные файлики.
P.S. С выходом .Net7.0 класс Startup вообще не нужен, но об этом уже в другой статье.