Что такое MVC, модель, вид и контроллер

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

Умеете ли вы объяснить разделение ответственности своими словами и приложить его к тому, с чем реально работаете. У питониста вопрос почти всегда продолжается уточнением про Django или Flask, и там начинается самое интересное: терминология фреймворка не совпадает с классической.

Как отвечать

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

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

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

Полезно назвать соседей: в MVP посредник берёт логику отображения на себя, в MVVM представление связано с моделью представления через привязку данных.

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

Называют контроллером файл маршрутов, а обработчик представлением. Это калька с чужой терминологии; в разговоре про Django стоит сразу сказать, что там роли зовутся иначе, и показать соответствие с классической тройкой.

Складывают всю логику в обработчик запроса. Проверка прав, расчёт, отправка письма и поход во внешний сервис в одной функции на двести строк тестируются только через HTTP и не переиспользуются нигде.

Сводят модель к классу ORM. Таблица это про хранение, а не про предметную область; когда правила размазаны по обработчикам, одно и то же условие отмены заказа живёт в трёх местах и однажды расходится.