|
Table of contents
|
Прежде чем мы погрузимся в изучение кода, давайте рассмотрим общий дизайн БД ориентированных веб-приложений Django. Как мы рассказывали в предыдущих главах, Django поощряет свободное связывание и строгое разделение частей приложения. Если следовать этой философии, то легко вносить изменения в одну конкретную часть приложения без ущерба для остальных частей. В функциях представления, например, мы обсуждали важность отделения бизнес-логики от логики отображения с помощью шаблонной системы. Используя слой для работы с базой данных, мы применяем эту же философию для логики доступа к данным. Эти три вещи вместе — логика доступа к данным, бизнес-логика и логика отображения — составляют концепцию, которую называют шаблоном Модель-Представление-Управление (Model-View-Controller, MVC) архитектуры программного обеспечения. В этой концепции термин «Модель» относится к логике доступа к данным; термин «Представление» относится к той части системы, которая определяет, что показать и как; а термин «Управление» относится к той части системы, которая определяет какое представление надо использовать, в зависимости от пользовательского ввода, по необходимости получая доступ к модели.
Почему используется сокращение?Целью чёткого определения сокращений, подобных MVC, является упорядочивание взаимодействия между разработчиками. Вместо того, чтобы сказать вашим сотрудникам: «Давайте использовать абстрактный доступ к данным, затем создадим слой управления отображением данных и тогда создадим слой между ними, который всем этим управляет» можно воспользоваться общим термином: «Давайте здесь использовать подход MVC».
Django следует модели MVC достаточно близко, т.е., может быть назван MVC совместимой средой разработки. Вот примерно как M, V и C используются в Django:
Так как «C» обрабатывается средой разработки и всё интересное в Django происходит в моделях, шаблонах и представлениях, на Django ссылаются как на MTV-ориентированную среду разработки. В MTV-подходе к разработке:
Если вам приходилось работать с другими MVC ориентированными средами разработки, такими как Ruby on Rails, вы можете рассматривать представления в Django как «контролёры», а шаблоны Django — как «представления». Это печальная путаница возникла в результате различных толкований MVC. В интерпретации Django «представление» описывает данные, которые будут представлены пользователю. Неважно как эти данные будут выглядеть, важно какие данные. Напротив, в Ruby on Rails и подобных ему средах предполагается, что в работу контролёра включено принятие решения, какие данные будут представлены пользователю, в то время как представление точно определяет как эти данные будут выглядеть, а не какие данные будут представлены. Ни одна интерпретация не имеет преимуществ над другой. Важно понимать основную концепцию. |
Found misprint?
Select it with the mouse and hit Enter
-
Processed:
33
1
199
25
The full repository of DjangoBook translation you can get on GitHub.
We appreciate your patches!
We are glad to hear your questions, comments or suggestions!
(Open in new tab)
Users number: 601
Русская группа
Ускорить процесс перевода!
ЯМ:41001223475816
|
| © 2008-2012 Ruslan Popov @ gmail.com | Powered by Django 1.2.5 |
reply to sintsov.denis
После PHP и CodeIgniter была большая путаница. "Шаблоны, представления, модели, а где контроллеры?" - думал я. Теперь все ясно.
Желательно рассказать в самом начале об этом.
О чем и в начале чего?
Я как-то пытался сделать аналог контролера, как в Pylons, но без патчинга кода Django - никак. Да и не зачем в принципе.
После PHP и CodeIgniter была большая путаница. "Шаблоны, представления, модели, а где контроллеры?" - думал я. Теперь все ясно.
Желательно рассказать в самом начале об этом.
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
Вроде правильно все. View определяет логику - что показывать, а Template - как показывать.
Кажется, в модели MVT перепутано определение T и V.