Django:" проекты " vs " приложения"

Question

Django:" проекты " vs " приложения"

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

проекты могут иметь многие приложения. Приложения могут быть разделены между многими проектами. Штраф.

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

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

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

765 6

python django namespaces project-organization

6 ответов:

Comments

Ничего не найдено.

score 52 · Accepted Answer · 2011-02-02 21:58:21

что такое, чтобы остановить вас, используя 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, функцию (обычно пакет.пакет.просмотр.имя_функции) он будет обработан. Просто. Все эти"проекты"/" приложения " - это просто пакеты python.

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

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

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

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

настройка Django по умолчанию не делает этого.

часто я хочу создать основное приложение, поэтому я создаю одно, обычно называемое website. Однако позже я, возможно, захочу разработать оригинальную функциональность только для этого сайта. Чтобы сделать его съемным (независимо от того, делаю ли я это когда-либо), я обычно создаю отдельный каталог. Это также означает, что я могу отказаться от указанной функциональности, просто разорвав связь пакет из конфигурации и удаление папки, а не сложное удаление правильных URL-адресов из глобального urls.py папка.

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

моя папка верхнего уровня часто содержит несколько других вещей, включая, но не ограничиваясь сценариями wsgi, сценарии sql так далее.

Джанго управление расширениями полагаться на подкаталоги. Поэтому имеет смысл называть пакеты соответствующим образом.

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

claymation · Accepted Answer · 2017-10-15 00:56:55

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

для небольших сайтов вполне разумно иметь что-то вроде:
site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py

Ski · Accepted Answer · 2015-04-27 18:46:48

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

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

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

JooMing · Accepted Answer · 2011-02-02 21:54:31

Я нашел следующие сообщения в блоге очень полезными о приложениях и проектах 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 для организации исходного кода вашего продукта.

crodjer · Accepted Answer · 2011-02-02 23:22:37

если это так... с точки зрения проекта Джанго.пространство имен приложений, моя склонность к usemyproduct.myproduct, но, конечно, это не допускается

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

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

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

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

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

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

в общем проекте.подход к приложению django автоматически определяет схему sql из моделей.

ваш проект было бы гораздо проще построить с обычным подходом.

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

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

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

Qback · Accepted Answer · 2017-12-05 12:33:20

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

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

затем вы можете создать приложение django с именем, например, "FrontEnd"

затем вы создаете некоторые серверные приложения. Например, приложение с именем "комментарии", которое будет хранить комментарии пользователей. И приложение "комментарии" ничего не будет отображать само по себе. Это будет просто API для AJAX запросов вашего динамическийJSсайт.

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