Ответ 1

Разделение views.py

Большая часть вашего кода, вероятно, ожидает, что ваши представления будут доступны как myapp.views.viewname. Один из способов, с помощью которых я видел людей, разбивать свои взгляды, но сохранить это имя python, чтобы создать каталог views/. views/__init__.py будет иметь:

from .foo_views import *
from .bar_views import *
from .baz_views import *

Затем в views/foo_views.py поместите:

def foo_detail(request, ...):
    # your code here

def foo_list(request, ...):
    # your code here

def your_other_view(...):
    # ...

и т.д.. Поэтому вы перемещаете все из views.py в файлы в этом каталоге, делаете __init__.py, удаляете views.py, и все готово.

Затем, когда вы import myapp.views, myapp.views.foo_detail будет ссылаться на функцию, определенную вами в views/foo_views.py.

Разделение других модулей

Эта стратегия также должна хорошо работать для admin.py и т.д. Но если вы хотите разделить models.py как это, вам нужно добавить app_label = 'your_app_name' в class Meta: все ваши модели. Например, unicorn_app/models/unicorns.py может иметь такую ​​запись:

class Unicorn(models.Model):
    description = models.CharField(max_length=80)

    class Meta:
        app_label = 'unicorn_app'

(В противном случае Django полагает, что модель Unicorn является частью приложения Django с именем "models", которое испортило админ-сайт. Current through 1.6 - предстоящий выпуск 1.7 удалит это требование.)

Ответ 2

В качестве общего руководства подумайте о удобочитаемости и ремонтопригодности: по умолчанию "views.py" - это просто предложение, сделанное начальными строительными лесами - вам не нужно придерживаться к нему.

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

Наконец, вы также можете подумать о других способах упрощения вашего приложения.
Вы видите дублированный код? Может быть, некоторые функции могут быть перемещены в совершенно другом приложении? И так далее.

Ответ 3

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

Например, у вас может быть следующая структура:

main_app/
  |_models.py
  |_views.py
  |_forms.py
  |_urls.py
  |_templates/

sub_app_1/
  |_views.py
  |_forms.py
  |_urls.py
  |_templates/

sub_app_2/
  |_views.py
  |_forms.py
  |_urls.py
  |_templates/