Как разбить контроллеры (представления) на связные файлы в проекте Django?

Question

В настоящее время я работаю над учебником на сайте Django. После выполнения следующей команды:

python manage.py startapp polls

создает следующую структуру:

polls/
    __init__.py
    models.py
    tests.py
    views.py

Когда я просматривал учебник, мне пришло в голову, что файл views может вырасти до этого огромного несвязного монолитного файла, который выполняет каждое действие во всем веб-приложении.

Есть ли способ разбить этот файл на связные классы или файлы? Я попытался изменить settings.py и url.py, чтобы они указывали на другой каталог, но похоже, что скрипт, который генерирует структуру файла, создает модуль "views" при создании файла, и я не вижу способа изменить / переопределить это поведение из скрипта.

Answer 1

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

http://www.nomadjourney.com/2009/11/splitting-up-django-models/

например

/myapp

    * /views
          o __init__.py
          o bar.py
          o foo.py

с соответствующими инструкциями импорта в файле __init__.py

Это может подойти для расширяющегося приложения. Кроме того, представления более гибкие, чем модели, так как они могут быть структурированы, так что вы можете использовать backend / members / frontend / modules или просто admin_views.py и т. Д.

Answer 2

Функции представления не обязательно должны быть в views.py, они могут быть где угодно, если они правильно отображаются в urls.py. Так что вам решать, как вы организуете свой проект.

но похоже, что скрипт, который генерирует структуру файла, создает модуль "views" при создании файла, и я не вижу способа изменить / переопределить это поведение из скрипта.

Вы можете полностью игнорировать этот сценарий и то, что он генерирует. Это не делает ничего волшебного за кулисами; он просто создает эти файлы для вас.

Answer 3

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

Например, у меня есть декоратор post_limit, который проверяет, изменил ли пользователь недавно какой-либо экземпляр в определенной модели (настраиваемое представление по представлению), и выдает ошибку, если она есть, в качестве средства защиты от наводнений.

На самом деле, многие представления работают так схожим образом, что они даже не получают свои собственные тела функций, я просто заключаю общие представления в соответствующие декораторы, и единственными представлениями, которые получают много пользовательского кода, являются сайты типа агрегации, такие как целевая страница, которая собирает много различной информации тонкими способами, чтобы они выглядели «просто правильно»

Answer 4

Я недавно работал над этим учебником. Я предполагал, что большая часть «базовой» логики будет переходить к различным классам или методам в других вспомогательных файлах. Тогда views.py будет содержать базовые вызовы для установки и выполнения методов.

Учитывая этот дизайн, я ожидаю, что одна функция представления может иметь от 3 до 5 строк кода. Настройка, выполнение метода и возврат.

По сути, я имею в виду реализацию шаблона Facade .

Я ожидаю, что в руководстве не используется этот подход, потому что он добавляет уровни перенаправления (неправильное направление?), Которые могут усложнить для ученика следовать коду.

Answer 5

У каждого приложения, которое вы создаете для проекта, будет свой собственный файл views.py (при условии, что он использует представления), поэтому вам не нужно беспокоиться о том, что оно станет монолитным.

Просто убедитесь, что функциональность ваших приложений сфокусирована.

Из документации Django:

Проекты и приложения

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