Что такое контроллер в ASP.NET Core MVC

Что проверяют

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

Как отвечать

Контроллер это класс, которому маршрутизация передаёт запрос после промежуточного слоя. Метод действия принимает связанную из запроса модель, зовёт прикладной сервис и возвращает результат: представление, данные или код состояния. Экземпляр создаётся на каждый запрос, зависимости приходят через конструктор из контейнера служб.

Что стоит проговорить:

• Controller против ControllerBase: первый умеет представления, второй берут для веб-API, где они не нужны;
• атрибут ApiController включает автоматическую проверку модели, вывод источника связывания и ответ с описанием проблемы при ошибке;
• маршрутизация бывает по соглашению и атрибутами, для веб-API берут атрибуты;
• результат валидации смотрят в ModelState, а сквозные заботы вроде журналирования и авторизации выносят в фильтры и промежуточный слой.

Заканчивать лучше мыслью про тонкий контроллер: он разбирает вход, делегирует работу и переводит исход в код ответа. Если представления и фильтры не нужны вовсе, разумной альтернативой будут минимальные конечные точки, и понимание границы между двумя подходами тоже засчитывается.

Где спотыкаются

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

Оборачивают каждое действие в try и catch со своим текстом ошибки. Централизованная обработка через фильтр исключений или промежуточный слой даёт единый формат ответа и не расползается дублированием по проекту.

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