Джанго: «проекты» против «приложений»

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

Проекты могут иметь много приложений. Приложения могут быть использованы многими проектами. Хорошо.

Я не заново изобретаю блог или форум - я не вижу, чтобы какая-то часть моего продукта могла быть повторно использована в каком-либо контексте. Интуитивно я бы назвал это «приложение». Затем я делаю всю свою работу в одной папке "приложения"?

Если так ... с точки зрения project.appпространства имен Django , я склонен использовать myproduct.myproduct, но, конечно, это не разрешено (но приложение, которое я создаю, - это мой проект, а мой проект - приложение!). Поэтому я склонен полагать, что, возможно, я должен подходить к Django, создавая одно приложение для «значимой» модели, но я не знаю, где провести границы в моей схеме, чтобы разделить ее на приложения - у меня много моделей с относительно сложными отношениями.

Я надеюсь, что есть общее решение для этого ...

Что мешает вам использовать myproduct.myproduct? То, что вам нужно для этого, примерно состоит в следующем:

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

и так далее. Поможет ли это, если я скажу, что мне views.pyне нужно звонить views.py? При условии, что вы можете назвать в пути python функцию (обычно package.package.views.function_name), с которой она будет обрабатываться. Просто как тот. Все эти "проекты" / "приложения" просто пакеты Python.

Теперь, как ты должен это сделать? Или, скорее, как я могу это сделать? Ну, если вы создаете значительную часть многоразовой функциональности, как , скажем , редактор разметки, это при создании «приложения верхнего уровня» , которые могут содержать widgets.py, fields.py, и context_processors.pyт.д. - все вещи , которые вы могли бы хотеть импорт.

Точно так же, если вы можете создать что-то вроде блога в формате, который является довольно общим для установок, вы можете обернуть его в приложении, с его собственным шаблоном, папкой статического содержимого и т. Д., И настроить экземпляр проекта django для использования этого содержание приложения.

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

Тем не менее, для решения вашей реальной проблемы, да, ничего не говорит, что вы не можете работать с папкой проекта верхнего уровня. Это то, что делают приложения, и вы можете сделать это, если действительно хотите. Я, как правило, не по нескольким причинам:

• Настройки Django по умолчанию этого не делают.
• Часто я хочу создать основное приложение, поэтому я создаю его, обычно называемое website. Однако позже я мог бы захотеть разработать оригинальную функциональность только для этого сайта. Чтобы сделать его съемным (независимо от того, делаю я это или нет), я, как правило, создаю отдельный каталог. Это также означает, что я могу отказаться от упомянутой функциональности, просто отсоединив этот пакет от конфигурации и удалив папку, а не сложное удаление нужных URL-адресов из глобальной папки urls.py.
• Очень часто, даже когда я хочу сделать что-то независимое, ему нужно где-то жить, пока я за ним присматриваю / делаю это независимым. В основном вышеприведенный случай, но для вещей, которые я намерен сделать обобщенным.
• Моя папка верхнего уровня часто содержит несколько других вещей, включая, помимо прочего, сценарии wsgi, сценарии sql и т. Д.
• Расширения управления django опираются на подкаталоги. Поэтому имеет смысл называть пакеты соответствующим образом.

Короче говоря, причина, по которой существует соглашение, такая же, как и у любого другого соглашения - это помогает, когда дело касается других, работающих с вашим проектом. Если я увижу, fields.pyя сразу ожидаю, что код в нем подклассирует поле django, тогда как, если я увижу, у inputtypes.pyменя может быть не совсем понятно, что это значит, не глядя на него.

После того как вы закончите использование startprojectи startapp, ничто не помешает вам объединить «проект» и «приложение» в одном пакете Python. Проект на самом деле является не чем иным, как settingsмодулем, а приложение - не более чем modelsмодулем - все остальное не является обязательным.

Для небольших сайтов вполне разумно иметь что-то вроде:

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py

Попробуйте ответить на вопрос: «Что делает мое приложение?». Если вы не можете ответить в одном предложении, то, возможно, вы можете разделить его на несколько приложений с более чистой логикой.

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

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

Я нашел следующие сообщения в блоге очень полезными о приложениях и проектах django:

• http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
• http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/

В принципе, у вас есть большая свобода с django для организации исходного кода вашего продукта.

Если так ... с точки зрения пространства имен Django project.app, я склонен использовать myproduct.myproduct, но, конечно, это не разрешено

Там ничего подобного не допускается. Это ваш проект, никто не ограничивает вас. Желательно сохранить разумное имя.

Я не вижу, чтобы какая-либо часть моего продукта использовалась повторно в любом контексте. Интуитивно я бы назвал это «приложение». Затем я делаю всю свою работу в одной папке "приложения"?

В общем проекте django есть много приложений (contrib-приложений), которые действительно используются в каждом проекте.

Допустим, ваш проект выполняет только одну задачу и имеет только одно приложение (я mainназываю его так, как проект вращается вокруг него и вряд ли может быть подключен). Этот проект также все еще использует некоторые другие приложения вообще.

Теперь, если вы говорите, что ваш проект использует только одно приложение ( INSTALLED_APPS='myproduct'), так что толку от projectопределения проекта как project.app, я думаю, вы должны рассмотреть некоторые моменты:

• Есть много других вещей, которые обрабатывает код, отличный от приложения в проекте (базовые статические файлы, базовые шаблоны, настройки .... т.е. обеспечивает основу).
• В общем подходе project.app django автоматически определяет схему sql из моделей.
• Ваш проект будет гораздо проще построить с помощью обычного подхода.
• Вы можете определить несколько разных имен для URL-адресов, представлений и других файлов по своему усмотрению, но я не вижу необходимости.
• Возможно, вам потребуется добавить некоторые приложения в будущем, что было бы очень легко с обычными проектами django, которые в противном случае могут стать одинаково или более трудными и утомительными.

Что касается большей части работы, выполняемой в приложении, я думаю, что это относится к большинству проектов django.

Здесь создатели Django сами указывают на эту разницу . Я думаю, что хорошо думать о приложениях, так как они должны использоваться в других проектах . Также хорошим представлением о приложениях в Django предоставляют современные веб-приложения.

Представьте, что вы создаете большое динамическое веб-приложение на основе JavaScript .

Затем вы можете создать приложение в Django с именем, например, «FrontEnd» <- в приложении Thins вы будете отображать контент.

Затем вы создаете несколько бэкэнд-приложений. Например, приложение под названием «Комментарии», в котором будут храниться комментарии пользователей. А приложение «Комментарии» само по себе ничего не отображает. Это будет просто API для запросов AJAX вашего динамического сайта JS .

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