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 же, и других подобных фреймворках, предполагается что роль контроллера включает в себя выбор какие данные передать пользователю, тогда как представление определяет — как именно эти данные будут выглядеть, а не какие данные передавать.