Django Book: концепция разработки MVC

Предыдущая часть.

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

Как мы уже упомнили в предыдущих частях, Django разработана с особой поддержкой “слабых связей” и строгим разграничением составляющих частей приложения. Если вы следуете этой философии – то вам будет легко вносить изменения в одной части приложения, не затрагивая функциональность других. Например, в функциях представлений – мы обсуждали важность разделения структуры выполнения от структуры отображения, и поэтому использовали систему шаблонов. В случае с уровнем баз данных – мы будем применять ту же философию.

Весте эти три части – логика доступа к данным, логика исполнения и логика предоставления данных – составляют концепт, который обычно называют концепцией Model-View-Controller (MVC) (модель-представление-контроллер) архитектуры приложений. В этой схеме “Модель” относится к структуре данным, “Представление” – относится к части, которая отвечает за выборку того, что и как отображать, а “Контроллер” – относится к части, которая определяет какое представление использовать, например – в зависимости от ввода данных пользователя.

Почему акроним?

Цель явного определения шаблонов, таких как MVC, в основном для упрощения общения между разработчиками. Вместо того, что бы говорить вашему коллеге “Давай сделаем некую абстракцию уровня данных, затем отделим уровень, который будет заниматься отображением данных, а посредине добавим ещё один слой, который будет этим всем управлять” – вы можете просто скатать “Давай использовать модель MVC“.

Django следует концепции MVC достаточно строго, что бы его можно было называть “MVC фреймворк“. Вот краткое описание того, как M, V и C разделены в среде Django:

M – часть доступа к данным, обслуживается системой баз данных Django, которая описывается в этой главе.
V – часть, которая занимается выборкой того, что именно и как именно отображать, в Django этим занимаются представления (views) и шаблоны (templates).
C – часть, которая определяет представление в зависимости от указаний пользователя, этим занимается сам фреймворк, следуя настройкам URLconf и вызывая соответствующую функцию Python для заданного URL-а.

Так как “C” занимается сам фреймворк и больше всего действий происходит в моделях, шаблонах и представлениях, Django может называться “MVC фреймворком“.

В концепции MTV:

M означает “Model” – модель, уровень доступа к данным. Сюда относится всё, что связано с данными – как получить к ним доступ, как проверить их, какое у них поведение и отношение друг с другом.
T означает “Template” – шаблоны. Этот уровень содержит в себе всё, что связано с отображением: как именно что-то должно быть отображено на веб-странице или любом другом документе.
V означает “View” – представление. Этот уровень связан со всей логикой, связывающей модель и необходимые шаблоны. Вы можете себе представлять это уровень как мост между моделями и шаблонами.

Если вы знакомы с другими фреймворками MVC, такими как Ruby on Rails, вы можете рассматривать представления в Django как “контролеры”, а шаблоны Django – как представления. Эта путаница вызвана различным толкованием концепции MVC. В интерпретации Django, представление (view) описывает данные, которые должны быть представлены пользователю; т.е. не столько как они будут переданы, сколько какие именно данные передать. В Ruby on Rails же, и других подобных фреймворках, предполагается что роль контроллера включает в себя выбор какие данные передать пользователю, тогда как представление определяет – как именно эти данные будут выглядеть, а не какие данные передавать.