Timur2342
@Timur2342

В каких случаях создавать новые контроллеры?

У контроллера могут быть разные действия, например SignConroller может выполнять вход, выход, регистрацию в аккаунт. Нужно ли разбивать данный конроллер на 3 более мелких? Что предпочтительнее будет для других разработчиков?
  • Вопрос задан
  • 56 просмотров
Пригласить эксперта
Ответы на вопрос 3
@mvv-rus
Настоящий админ AD и ненастоящий программист
Одно из сображений, касающееся производительности. Контролллер - это класс, который создается каждый раз для обработки запроса.
Поэтому имеет смысл смотреть на сервисы-зависимости в его конструкторе (параметры конструктора, которые извлекаются из контейнера сервисов): если действия этого контроллера используют разные зависимости, особенно - с временем жизни Scoped (DatabaseContext, к примеру) или Transient, то эти действия - хорошие кандидаты на перенос в отдельный(е) контроллер(ы).
Ответ написан
Комментировать
NikFaraday
@NikFaraday
Student full-stack Developer
Если вы работаете с Entity Framework, возьмите себе правило "Одна Entity - Один Controller". Потом сюда можете добавлять контроллеры для логических единиц в виде следующих:
  • Авторизация. Для подобных действий в системе всегда должен использоваться отдельный контроллер. Регистрация, вход в систему, выход из системы, проверка существования пользователя, получить текущего авторизированного пользователя и т.д.
  • Файлы. Загрузить, удалить, получить, конвертировать и т.д.
  • Статистика. Обновить статистику, получить и т.д.
  • Другие действия, действия с которыми не полностью покрывают взаимодействие с самой Entiy, а только лишь с некими данными, но таких действий может быть очень много (Для примера AuthenticationController)
Ответ написан
Комментировать
vabka
@vabka Куратор тега ASP.NET
Токсичный шарпист
1. Не соглашусь с идеей "одна entity-один контроллер", так как сущности из EF далеко не всегда 1-в-1 маппятся на сущности твоего api

2. Проблема с DI логична, но далеко не всегда является проблемой. При достаточном желании можно настроить всё так, что у тебя все объекты, включая контроллеры и DAL будут Singletone (на одном проекте мы так сделали и это сильно увеличило производительность и снизило нагрузку на память).
Но вообще да - если у тебя в контроллере очень много зависимостей и в разных методах используются разные наборы этих зависимостей - значит что-то идёт не так и надо разделять (но не факт).
Помни ещё, что кроме инъекции в конструктор можно инжектить в параметры метода при помощи атрибута [FromServices]

3. Я предпочитаю группировать по сущностям api.
Тоесть если у меня будут сущности /orders, /items, то тогда у меня будет два контроллера: OrdersController и ItemsController - это упрощает поддержку и делает расположение методов логичным и очевидным.
=> Тактика по разбиению SignInController из вопроса будет зависеть от того, по каким url доступно каждое из его действий.

Ну и ещё наброшу:
Существует minimal api в котором нет контроллеров
https://learn.microsoft.com/en-us/aspnet/core/fund...
https://github.com/CarterCommunity/Carter

Существует практика создавать для каждого endpoint - свой класс.
https://github.com/ardalis/ApiEndpoints
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы