Django:" проекты "vs" приложения"
у меня есть довольно сложный "продукт", который я готов построить с помощью Django. Я собираюсь избегать использования терминов "проект" и "приложение" в этом контексте, потому что я не понимаю их конкретного значения в Django.
проекты могут иметь многие приложения. Приложения могут быть разделены между многими проектами. Штраф.
Я не изобретаю блог или форум - Я не вижу, чтобы какая-либо часть моего продукта была повторно использована в любом контексте. Интуитивно я бы назвал это "приложением"."Я тогда сделайте всю мою работу в одной папке "app"?
если так... с точки зрения пространство имен, моя склонность использовать myproduct.myproduct, но, конечно, это не разрешено (но приложение, которое я создаю, - это мой проект, и мой проект-это приложение!). Поэтому я считаю, что, возможно, я должен подойти к Django, построив одно приложение на "значительную" модель, но я не знаю, где рисовать границы в моей схеме, чтобы разделить ее на приложения - у меня есть множество моделей с относительно сложными отношениями.
Я надеюсь, что есть общее решение для этого...
6 ответов
что остановить вас с помощью 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 для использования этого приложения содержание.
нет жестких и быстрых правил, говорящих, что вы должны это сделать, но это одна из целей фреймворка. Тот факт, что все, включая шаблоны, позволяет вам включать из какой-то общей базы, означает, что ваш блог должен плотно вписываться в любую другую настройку, просто заботясь о своей собственной части.
однако, чтобы решить вашу фактическую проблему, да, ничто не говорит, что вы не можете работать с папкой проекта верхнего уровня. вот что делают приложения и вы можете сделать это если ты действительно хочешь. Однако я не склонен к этому по нескольким причинам:--11-->
- настройка Django по умолчанию этого не делает.
- часто я хочу создать основное приложение, поэтому я создаю его, обычно называемое
website. Однако позже я, возможно, захочу разработать оригинальную функциональность только для этого сайта. Чтобы сделать его съемным (независимо от того, делаю я это или нет), я обычно создаю отдельный каталог. Это также означает, что я могу отказаться от указанной функциональности, просто разблокируя это пакет из конфигурации и удаление папки, а не сложное удаление правильных URL-адресов из глобального urls.py папка. - очень часто, даже когда я хочу сделать что-то независимое, ему нужно где-то жить, пока я забочусь о нем / делаю его независимым. В основном приведенный выше случай,но для вещей я намерен сделать общий.
- моя папка верхнего уровня часто содержит несколько других вещей, включая, но не ограничиваясь сценариями wsgi, сценарии sql так далее.
- Джанго управление расширениями полагаться на подкаталоги. Поэтому имеет смысл называть пакеты соответствующим образом.
короче говоря, причина, по которой существует конвенция, такая же, как и любая другая конвенция - это помогает, когда дело доходит до других, работающих с вашим проектом. Если я увижу 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.пространство имен приложений, моя склонность к usemyproduct.myproduct, но, конечно, это не допускается
нет ничего, как не допускается. Это ваш проект, никто вас не ограничивает. Желательно сохранить разумное имя.
Я не вижу, чтобы какая-либо часть моего продукта была повторно использована в любом контексте. Интуитивно я бы назвал это "приложением"."Делаю ли я тогда всю свою работу в одном" приложении" папка?
В общем проекте django есть много приложений (приложений contrib), которые действительно используются в каждом проекте.
предположим, что ваш проект выполняет только одну задачу и имеет только одно приложение (я называю его main поскольку thethe проект вращается вокруг него и вряд ли подключается). Этот проект тоже использует некоторые другие приложения в целом.
теперь, если вы говорите, что ваш проект используя только одно приложение (INSTALLED_APPS='myproduct') Итак, что такое использование project определение проект как project.app, Я думаю, вы должны учесть некоторые моменты:
- есть много других вещей, которые обрабатывает код, отличный от приложения в проекте (базовые статические файлы, базовые шаблоны, настройки....т. е. предоставляет базу).
- в общем проекте.app app app approach django автоматически определяет схему sql из моделей.
- ваш проект будет намного проще построить с помощью обычного подхода.
- вы можете определить некоторые разные имена для URL, представлений и других файлов, как вы хотите, но я не вижу необходимости.
- вам может потребоваться добавить некоторые приложения в будущем, которые будут очень легко с обычными проектами django, которые в противном случае могут стать одинаково или более трудными и утомительными.
Что касается большинства работ, выполняемых в приложении, я думаю, что это относится к большинству проектов django.
здесь создатели Django указывают на эту разницу сами. Я думаю, что думать о приложениях, как они должны быть многоразовые в других проектах это хороший. Также хороший способ думать о приложениях в Django предоставляют современные веб-приложения.
представьте, что вы создаете big динамический веб-приложения на основе JavaScript.
вы можете создать затем в приложении django с именем e.g "FrontEnd"
затем вы создаете некоторые бэкэнд-приложения. Например, приложение с именем "комментарии", которое будет хранить комментарии пользователей. И приложение "комментарии" ничего не будет отображать само по себе. Это будет просто API для AJAX-запросов вашего динамический JS сайт.
таким образом, вы всегда можете повторно использовать приложение "комментарии". Вы можете сделать его открытым исходным кодом, не открывая источник всего проекта. А ты держи себя в чистоте!--3-->логика вашего проект.