Прежде чем мы погрузимся в изучение кода, давайте рассмотрим общий дизайн БД ориентированных веб-приложений Django.

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

Эти три вещи вместе — логика доступа к данным, бизнес-логика и логика отображения — составляют концепцию, которую называют шаблоном Модель-Представление-Управление (Model-View-Controller, MVC) архитектуры программного обеспечения. В этой концепции термин «Модель» относится к логике доступа к данным; термин «Представление» относится к той части системы, которая определяет, что показать и как; а термин «Управление» относится к той части системы, которая определяет какое представление надо использовать, в зависимости от пользовательского ввода, по необходимости получая доступ к модели.

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

Так как «C» обрабатывается средой разработки и всё интересное в Django происходит в моделях, шаблонах и представлениях, на Django ссылаются как на MTV-ориентированную среду разработки. В MTV-подходе к разработке:

Если вам приходилось работать с другими MVC ориентированными средами разработки, такими как Ruby on Rails, вы можете рассматривать представления в Django как «контролёры», а шаблоны Django — как «представления». Это печальная путаница возникла в результате различных толкований MVC. В интерпретации Django «представление» описывает данные, которые будут представлены пользователю. Неважно как эти данные будут выглядеть, важно какие данные. Напротив, в Ruby on Rails и подобных ему средах предполагается, что в работу контролёра включено принятие решения, какие данные будут представлены пользователю, в то время как представление точно определяет как эти данные будут выглядеть, а не какие данные будут представлены.

Ни одна интерпретация не имеет преимуществ над другой. Важно понимать основную концепцию.