Менталитет программирования веб-фреймворков [закрыто]

Я только начинаю играть с Django / Python и пытаюсь перейти в режим программирования MTV, который требует Django (настаивает на). Решение о том, какие функции должны быть методами модели, а не просто быть функцией в представлении, до сих пор сбивает с толку. Кто-нибудь знает книгу, веб-сайт, блог, слайд-шоу, что-либо, что обсуждает программирование Web Framework в более общих, абстрактных терминах? Я думаю, что просто книга по объектно-ориентированному программированию сделает это, но я чувствую, что это было бы излишним - я искал что-то специфическое для веб-фреймворка.

22.08.2008 12:34:32
6 ОТВЕТОВ

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

0
22.08.2008 12:47:09

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

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

0
22.08.2008 13:05:48

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

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

1
22.08.2008 13:23:43

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

0
22.08.2008 13:32:35

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

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

Но два оставшихся термина могут сбивать с толку; где Django говорит о Views, «остальной мир» говорит о Controllers. Основная идея заключается в том, что именно здесь представлена ​​логика представления. Вычисления вычисляются, массивы сортируются, данные извлекаются и т. Д. Я бы сказал, что диспетчер URL-адресов Django также является частью традиционной концепции Controller.

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

Итак, резюмируем:

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

О, кстати: для руководства по Django, почитайте книгу The Django

1
22.08.2008 18:37:17

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

1
16.10.2008 20:36:41