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

Question

[Timur]

У контроллера могут быть разные действия, например SignConroller может выполнять вход, выход, регистрацию в аккаунт. Нужно ли разбивать данный конроллер на 3 более мелких? Что предпочтительнее будет для других разработчиков?

Comments

[Михаил Р.]

например SignConroller может выполнять вход, выход, регистрацию в аккаунт. Нужно ли разбивать данный конроллер на 3 более мелких?

Я бы отталкивался от объёма кода.

Answer 1

[MVV]

Одно из сображений, касающееся производительности. Контролллер - это класс, который создается каждый раз для обработки запроса.
Поэтому имеет смысл смотреть на сервисы-зависимости в его конструкторе (параметры конструктора, которые извлекаются из контейнера сервисов): если действия этого контроллера используют разные зависимости, особенно - с временем жизни Scoped (DatabaseContext, к примеру) или Transient, то эти действия - хорошие кандидаты на перенос в отдельный(е) контроллер(ы).

Answer 2

[Nik Faraday]

Если вы работаете с Entity Framework, возьмите себе правило "Одна Entity - Один Controller". Потом сюда можете добавлять контроллеры для логических единиц в виде следующих:

• Авторизация. Для подобных действий в системе всегда должен использоваться отдельный контроллер. Регистрация, вход в систему, выход из системы, проверка существования пользователя, получить текущего авторизированного пользователя и т.д.
  
• Файлы. Загрузить, удалить, получить, конвертировать и т.д.
  
• Статистика. Обновить статистику, получить и т.д.
  
• Другие действия, действия с которыми не полностью покрывают взаимодействие с самой Entiy, а только лишь с некими данными, но таких действий может быть очень много (Для примера AuthenticationController)
  

Answer 3

[Василий Банников]

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