Перенос мышления с CakePHP на Django - файл монолитных просмотров - PullRequest
4 голосов
/ 09 августа 2010

Я пытаюсь начать работу с Django, и ранее работал с CakePHP, и из этого вытекает мой опыт работы с MVC.Мне известна слегка отличающаяся архитектура MTV от Django, и я в порядке с файлами монолитной модели - несколько классов в одном файле я могу обрабатывать очень хорошо.

Но я не совсем понимаю, как делать представления (которыепримерно аналогичны контроллерам в MVC, верно?).В примерах, которые я видел, есть только один views.py, который имеет такие методы, как index(), view() и т. Д. Но если у меня есть группа пользователей, которые создают и владеют виджетами, которыми они могут поделиться, например, я бы хотел/users/view, который запускает view() для модели пользователей, и /widgets/view, который запускает view() для модели виджетов.

Я не вижу способа отделить их, и незнать, что правильный / обычный / правильный способ сделать это.У меня могут быть проблемы с тем, чтобы обернуть голову и в том, как Джанго что-то делает.Должны ли я иметь методы в view.py, которые user_view и widget_view?Это кажется очень неуклюжим.

Или я должен иметь user_view.py или даже user/view.py, который содержит index() и view()?Могу ли я ссылаться на них из маршрутизации URL?Как обычно дела обстоят с Джанго и подобными вещами?

В конечном итоге это может быть связано (или даже решено) с этим ответом , но я задаю еще один вопрос:какое соглашение и правильный способ думать о таких вещах.

Кроме того, разве документы / примеры не должны быть более ясными по этому поводу?До сих пор документы меня впечатлили, но я почти уверен, что большинство веб-приложений будут иметь дело с более чем одним «объектом», и мне кажется, что это встречается довольно часто.

1 Ответ

6 голосов
/ 09 августа 2010

Файлы представления Python - это просто модули Python.Сами представления - это просто функции, которые могут жить где угодно - модуль даже не нужно называть views.py.Urlconf (в urls.py) может вообще ссылаться на представления в любом месте.

Один очевидный способ разделения - на отдельные приложения, что хорошо описано в документации - у вас также может быть отдельный urls.pyфайлы для каждого приложения и используйте include в главном уровне сайта urls.py, чтобы включить все вложенные файлы.

Но ничто не мешает вам подразделить представления в одном приложении на несколько файлов - например, путем создания модуля views, содержащего (пустое) __init__.py и столько других файлов представления, сколько выкак.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...