Мышление программирования веб-фреймворка

Мое основное правило в Django: если вы могли бы предположительно нуждаться в функциональности откуда-то, кроме самого представления, она не принадлежит функции представления.

Я также рекомендую загрузить некоторые из множества приложений на Django Pluggables и посмотреть, как они это делают.

Как только вы найдете хорошее руководство, вот что нужно помнить: Django немного особенный со своей терминологией. Он использует "MTV" для модели, шаблона и представления (и может упомянуть также диспетчер URL где-то по пути), тогда как более стандартный набор терминов-"MVC" для модели, представления и контроллера.

Модель одинакова в обоих значениях-это модель объекта данных, часто связанная с таблицей базы данных, если платформа реализует объектно-реляционное отображение (что делает Django).

Но два оставшихся термина могут сбить с толку; там, где Django говорит о представлениях, "rest мира" говорит о контроллерах. Основная идея заключается в том, что именно здесь делается логика представления. Вычисления вычисляются, массивы сортируются, данные извлекаются и т.д. Я бы сказал, что диспетчер Django URL также является частью концепции обычного контроллера.

Шаблоны Django сопоставимы с представлениями в других местах - здесь у вас есть ваша презентация, ничего больше. Там, где Django вынуждает вас к очень небольшому набору логических команд, другие фреймворки часто просто рекомендуют вам не делать ничего, кроме present HTML, с некоторыми логическими элементами представления (такими как циклы, ветви и т. д.), Но не мешают вам делать другие вещи.

Итак, подведем итоги:

• Модель: объекты данных
• Контроллер (вид в Django): обработка данных
• Вид (шаблон в Django): презентация

О, Кстати: для конкретного руководства Django рассмотрите возможность чтения книги Django

Я действительно не использовал Django в anger раньше,но в Rails и CakePHP (и, соответственно, в любом веб-фреймворке MVC) подход Fat Model, Skinny Controller к организации ваших методов был для меня настоящим открытием.

Если вы не совсем настроены на погружение в Django и не возражаете попробовать что-то еще в качестве старта, вы можете дать WSGI шанс, который позволяет вам шаблонить свое приложение по-своему , используя сторонний движок, а не идти точно по правилам Django. Это также позволяет заглянуть на более низкий уровень обработки запросов, так что вы получите немного лучшее понимание того, что Django делает под капотом.

Вот несколько ссылок, которые могут быть полезны в качестве обзора.

По моему собственному опыту, когда я впервые начал использовать веб-фреймворки на основе MVC, самая большая проблема у меня была с моделями. Вырвать SQL из моих пальцев и заставить меня использовать предметы было просто странно. Как только я начал думать о своих данных как об объектах вместо операторов SELECT, мне стало легче.

• MVC в терминах непрофессионалов
• MVC: Самая Досадная Загадка
• Как использовать Model-View-Controller

Функция просмотра должна содержать только помощники отображения или логику отображения. Функции представления никогда не должны обращаться к самой модели, но должны принимать параметры данных модели. Важно отделить модель от представления. Поэтому, если функция обрабатывает доступ к базе данных или объектам базы данных, она принадлежит модели. Если функция обрабатывает форматирование отображения, она принадлежит представлению.