Почему структура папок Django REST Framework (DRF) отличается от Django Turorial?
Если вы следуете учебнику Django, вы выполните следующие команды:
django-admin startproject mysite
# Change into the outer mysite directory
cd mysite
python manage.py startapp polls
и вы получите такую структуру папок
mysite/
├── manage.py
│
├── mysite/
│ ├── __init__.py
│ ├── asgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
│
└── pools/
├── migrations/
│ └── __init__.py
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── views.py
Но если вы последуете Django REST Framework и выполните следующие команды:
Примечание: я заменил имена каталогов на совпадающие, для лучшего сравнения
# Create the project directory
mkdir mysite
cd mysite
# Set up a new project with a single application
django-admin startproject mysite . # Note the trailing '.' character
cd mysite
django-admin startapp polls
cd ..
и вы получите такую структуру папок
mysite/
├── manage.py
│
└── mysite/
├── __init__.py
├── asgi.py
├── settings.py
├── urls.py
├── wsgi.py
│
└── polls/
├── migrations/
│ └── __init__.py
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── views.py
Вот объяснение DFR:
Может показаться необычным, что приложение было создано в каталоге проекта. Использование пространства имен проекта позволяет избежать столкновения имен с внешними модулями (эта тема выходит за рамки данного краткого руководства).
.
Я хотел бы узнать больше об этой "теме, выходящей за рамки краткого руководства". Я хотел бы прочитать больше об этой теме и иметь некоторые примеры. Также, почему Django Tutorial учит тому, что "очевидно" имеет проблемы и "очевидно" не следует делать.
Если вы будете следовать руководству по Django REST framework, вы действительно получите описанную вами директорию. В документации мы видим, что структура файлов выглядит следующим образом:
.
./manage.py
./tutorial
./tutorial/__init__.py
./tutorial/quickstart
./tutorial/quickstart/__init__.py
./tutorial/quickstart/admin.py
./tutorial/quickstart/apps.py
./tutorial/quickstart/migrations
./tutorial/quickstart/migrations/__init__.py
./tutorial/quickstart/models.py
./tutorial/quickstart/tests.py
./tutorial/quickstart/views.py
./tutorial/settings.py
./tutorial/urls.py
./tutorial/wsgi.py
Если мы поместим это в древовидную структуру, то увидим:
.
├── manage.py
└── tutorial
├── __init__.py
├── quickstart
│ ├── admin.py
│ ├── apps.py
│ ├── __init__.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
├── settings.py
├── urls.py
└── wsgi.py
Но это не та же структура кода, которую используют учебники Django, в этом случае мы создаем структуру проекта с:
# Create the project directory
mkdir mysite
cd mysite
# Set up a new project with a single application
django-admin startproject mysite .
# no cd mysite
django-admin startapp polls
cd ..
тогда каталог проекта будет выглядеть так:
.
./manage.py
./tutorial
./tutorial/__init__.py
./quickstart
./quickstart/__init__.py
./quickstart/admin.py
./quickstart/apps.py
./quickstart/migrations
./quickstart/migrations/__init__.py
./quickstart/models.py
./quickstart/tests.py
./quickstart/views.py
./tutorial/settings.py
./tutorial/urls.py
./tutorial/wsgi.py
или, таким образом, в виде дерева файлов:
.
├── manage.py
├── quickstart
│ ├── admin.py
│ ├── apps.py
│ ├── __init__.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
└── tutorial
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py
Вы вызываете django-admin startapp polls
в каталоге root, поэтому каталог outer mysite
, а не inner .mysite
Причина, по которой фреймворк Django REST советует использовать этот дополнительный слой, заключается в том, чтобы избежать столкновения имен. Если вы, например, хотите назвать приложение zipfile
, то это столкнется с модулем пакета zipfile
[Python-docs], и тогда ваши модули больше не смогут ссылаться на элементы пакета zipfile
.
Вкладывая их в имя проекта, вы тем самым делаете эти модули доступными как from nameofawesomeproject.zipfile
, и таким образом вы все еще можете import zipfile
для пакета.
Метки приложений, однако, не изменяются автоматически: имя приложения по умолчанию является именем самого глубоко вложенного имени модуля, поэтому для django.contrib.auth
оно будет auth
. Вы можете задать другое имя, реализовав AppConfig
для вашего проекта.