Python: Веб-разработка (Flask)
2026-02-26 17:16 Diff
https://ru.hexlet.io/courses/python-flask/lessons/mvc/theory_unit

Последовательность запрос-обработка-ответ — основа, на которую нанизывается все остальное. Фреймворки идут дальше и разделяют приложение на дополнительные слои уже внутри самого процесса обработки запроса. Без такого разделения код быстро превращается в мешанину из запросов к базе данных, формирований HTML и логики обработки данных. Но с помощью MVC можно выполнять операции отдельно друг от друга.

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

Что такое MVC

Из обработки запроса естественным образом по порядку выделяются следующие слои шаблонов:

  • Model — модель
  • View — представление
  • Controller — контроллер

Остальное добавляется по мере роста сложности приложения. В итоге из этих трех слоев мы и получаем аббревиатуру MVC (Model-View-Controller) — архитектурный паттерн построения пользовательских приложений.

Существует две версии MVC. Первую придумали изначально в сообществе программистов на SmallTalk. Она создавалась под толстые клиенты, а они представляют собой событийные системы, как современные фронтенд-приложения.

На сервере используется другая вариация MVC, которая называется MVC v2. Буквы в ней те же, но означают местами другое. И самое главное, что совсем по-другому строится взаимодействие:

Архитектурный шаблон MVC задает основную структуру приложения и позволяет коду достаточно долго развиваться. При этом он остается удобным в поддержке. MVC с некоторыми модификациями реализуется всеми веб-фреймворками.

Model

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

Слой модели отвечает за бизнес-логику приложения и данные, которые с ней связаны. Технически этот слой может быть представлен большим количеством разных способов, которые зависят от конкретного языка программирования и используемых библиотек. Самый распространенный вариант — это ORM. Но так бывает не все��да. Часто даже при наличии отдельного слоя модели часть логики все же проникает в контроллеры.

Чтобы понять, зачем понадобилось выделять слой модели, прочитайте статью Rails is not your application.

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

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

Как видно, на логическом уровне есть граница между кодом, который моделирует предметную область и обслуживает веб-запросы. Но эту границу иногда трудно провести.

Например, сложно сразу определить, к чему относится отправка письма при регистрации, авторизации или восстановлении пароля. Если смотреть еще глубже, то возникают понятия Application Logic и Business Logic, а затем и Service Layer. Если вам интересно, то прочитайте про них самостоятельно.

Самая большая сложность в коде находится именно в этой части приложения. У модели нет четкой структуры, это не классическое запрос-обработка-ответ. Моделирование предметной области — это довольно сложная тема.

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

Контроллер инициирует различные процессы и запуск бизнес-логики. Еще он отвечает за формирование ответа и запускает рендеринг шаблонов. Шаблоны не знают про существование слоя контроллера, но используют данные, которые предоставлены им, чтобы формировать, например, HTML или JSON.

View

View или представление — это HTML-шаблон, который возвращает сервер после обработки запроса. Если запрос обрабатывается корректно, мы получим веб-страницу. Если запрос некорректный, мы попадем на страницу ошибки 404.

У шаблонов также есть свой язык, как Jinja2, который позволяет использовать циклы, условия, обрабатывать данные в шаблоне. Несмотря на широкие возможности языка шаблонов, не надо ими злоупотреблять, например, делать вызовы внешних функций или сложные преобразования данных. Все вычисления в модели MVC принято делать на стороне контроллеров, тогда как представление должно уже получать сформированные данные.

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

Controller

Под контроллерами понимаются обработчики запросов. Они принимают объект запроса и возвращают объект ответа. В случае Flask, контроллеры представлены функциями, но это не обязательно. В больших фреймворках контроллер — это класс, а обработчики — его методы. Эти методы обычно называют действиями — actions. При таком подходе вся логика сосредоточена в самих контроллерах, что вполне допустимо в самых примитивных случаях.