Прежде чем мы погрузимся в изучение кода, давайте рассмотрим общий дизайн БД ориентированных веб-приложений Django.
Как мы рассказывали в предыдущих главах, Django поощряет свободное связывание и строгое разделение частей приложения. Если следовать этой философии, то легко вносить изменения в одну конкретную часть приложения без ущерба для остальных частей. В функциях представления, например, мы обсуждали важность отделения бизнес-логики от логики отображения с помощью шаблонной системы. Используя слой для работы с базой данных, мы применяем эту же философию для логики доступа к данным.
Эти три вещи вместе — логика доступа к данным, бизнес-логика и логика отображения — составляют концепцию, которую называют шаблоном Модель-Представление-Управление (Model-View-Controller, MVC) архитектуры программного обеспечения. В этой концепции термин «Модель» относится к логике доступа к данным; термин «Представление» относится к той части системы, которая определяет, что показать и как; а термин «Управление» относится к той части системы, которая определяет какое представление надо использовать, в зависимости от пользовательского ввода, по необходимости получая доступ к модели.
Почему используется сокращение?
Целью чёткого определения сокращений, подобных MVC, является упорядочивание взаимодействия между разработчиками. Вместо того, чтобы сказать вашим сотрудникам: «Давайте использовать абстрактный доступ к данным, затем создадим слой управления отображением данных и тогда создадим слой между ними, который всем этим управляет» можно воспользоваться общим термином: «Давайте здесь использовать подход MVC».
Django следует модели MVC достаточно близко, т.е., может быть назван MVC совместимой средой разработки. Вот примерно как M, V и C используются в Django:
M, доступ к данным, обрабатывается слоем работы с базой данных, который описан в этой главе.
V, эта часть, которая определяет какие данные получать и как их отображать, обрабатывается представлениями и шаблонами.
C, эта часть, которая выбирает представление в зависимости от пользовательского ввода, обрабатывается самой средой разработки, следуя созданной вами схемой URL, и вызывает соответствующую функцию Python для указанного URL.
Так как «C» обрабатывается средой разработки и всё интересное в Django происходит в моделях, шаблонах и представлениях, на Django ссылаются как на MTV-ориентированную среду разработки. В MTV-подходе к разработке:
M определено для «Модели» (Model), слоя доступа к данным. Этот слой знает всё о данных: как получить к ним доступ, как проверить их, как с ними работать и как данные связаны между собой.
T определено для «Шаблона» (Template), слоя представления данных. Этот слой принимает решения относительно представления данных: как и что должно отображаться на странице или в другом типе документа.
V определено для «Представления» (View), слоя бизнес-логики. Этот слой содержит логику, как получать доступ к моделям и применять соответствующий шаблон. Вы можете рассматривать его как мост между моделями и шаблонами.
Если вам приходилось работать с другими MVC ориентированными средами разработки, такими как Ruby on Rails, вы можете рассматривать представления в Django как «контролёры», а шаблоны Django — как «представления». Это печальная путаница возникла в результате различных толкований MVC. В интерпретации Django «представление» описывает данные, которые будут представлены пользователю. Неважно как эти данные будут выглядеть, важно какие данные. Напротив, в Ruby on Rails и подобных ему средах предполагается, что в работу контролёра включено принятие решения, какие данные будут представлены пользователю, в то время как представление точно определяет как эти данные будут выглядеть, а не какие данные будут представлены.
Ни одна интерпретация не имеет преимуществ над другой. Важно понимать основную концепцию.
| Пред. | Уровень выше | След. |
| Глава 5. Модели | Начало | Настройка базы данных |
9 comments | Make a comment
Кажется, в модели MVT перепутано определение T и V.
Вроде правильно все. View определяет логику - что показывать, а Template - как показывать.
http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names
После PHP и CodeIgniter была большая путаница. "Шаблоны, представления, модели, а где контроллеры?" - думал я. Теперь все ясно.
Желательно рассказать в самом начале об этом.
answer to sintsov.denis
После PHP и CodeIgniter была большая путаница. "Шаблоны, представления, модели, а где контроллеры?" - думал я. Теперь все ясно.
Желательно рассказать в самом начале об этом.
О чем и в начале чего?
Я как-то пытался сделать аналог контролера, как в Pylons, но без патчинга кода Django - никак. Да и не зачем в принципе.
После CodeIgniter и особенно YII эта документация кажется, оччееень хорошо написаной и понятной)))
answer to intertrey
После CodeIgniter и особенно YII эта документация кажется, оччееень хорошо написаной и понятной)))
Это книга, линк на перевод официальной документации выше.
http://urfuclub.ru/blog/django-%D0%B2%D1%81%D1%8F-%D0%BF%D1%80%D0%B0%D0%B2%D0%B4%D0%B0-%D0%BE-%D1%82%D0%BE%D0%BC-mvc-%D0%BE%D0%BD%D0%BE-%D0%B8%D0%BB%D0%B8-mtv/ - некоторое прояснение формулировок.
Автор, в описании модели MVT вы перепутали местами определения для T и для V.