Какой паттерн проектирования является основополагающим в ASP.NET

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

Понимаете ли вы устройство фреймворка, а не только название шаблона проекта. Ответ «MVC» верен для классического ASP.NET MVC, но в ASP.NET Core фундамент глубже, и интервьюер ждёт, что вы это заметите. Следом обычно спрашивают про время жизни сервисов в DI.

Как отвечать

Начните с MVC, затем покажите, что лежит под ним:

• MVC: контроллер принимает запрос, работает с моделью, возвращает представление или данные. В Web API представления нет, контроллер отдаёт IActionResult или объект, который сериализуется в JSON;
• Dependency Injection: встроенный контейнер через IServiceCollection это основа ASP.NET Core, через него приходит всё, от ILogger<T> до DbContext. Три времени жизни: AddSingleton, AddScoped (экземпляр на HTTP-запрос), AddTransient;
• конвейер middleware: цепочка обработчиков, каждый решает, передать ли запрос дальше через next(). Это Chain of Responsibility, на нём держатся аутентификация, маршрутизация, обработка ошибок, и порядок подключения в Program.cs важен;
• Options: настройки через IOptions<T>, IOptionsSnapshot<T>, IOptionsMonitor<T> вместо чтения строк из IConfiguration;
• Front Controller: маршрутизация принимает все запросы в одной точке и раздаёт их обработчикам.

Добавьте, что MVC не единственный вариант: в Razor Pages разметка и обработчики OnGet и OnPost живут рядом, а Minimal APIs обходятся без контроллеров, но DI и middleware остаются теми же. Сильный ответ звучит так: исторически MVC, а в современном ASP.NET Core основа это DI и конвейер middleware.

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

Внедряют scoped-сервис, например DbContext, в singleton. Контекст живёт вечно и делится между потоками. В режиме разработки контейнер ловит это проверкой scope validation.

Путают фильтры MVC и middleware: фильтры работают только внутри MVC и знают про контроллер и модель, middleware видит весь запрос.

Кладут бизнес-логику в контроллер. Он раздувается и тестируется только через HTTP, правильнее вынести её в сервисы.