Когда нужно создать новое приложение (с startapp) в Django?

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

Должен ли я создать новое приложение для каждой функциональности на сайте, даже если оно использует модели из основного проекта?

Ребята, у вас есть хорошее правило, когда нужно отделить новое приложение и когда сохранить функциональность вместе с "основным проектом" или другими приложениями?

Ответ 1

Джеймс Беннет имеет замечательный набор слайдов о том, как организовать многоразовые приложения в Django.

Ответ 2

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

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

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

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

Ответ 3

Я стараюсь создавать новые приложения для каждого логически раздельного набора моделей. например:.

Профили пользователей
Сообщения форума
Сообщения в блоге

Ответ 4

Вот обновленная презентация 6 сентября 2008 года.

DjangoCon 2008: многоразовые приложения @7: 53

Слайд: Reusable_apps.pdf

Снято с горки

Должно ли это быть его собственным приложением?

Это совершенно не связано с фокусом приложений?

Это ортогонально тому, что я делаю?

Будут ли мне нужны аналогичные функции на других сайтах?
Если кто-то из них "Да"? Тогда лучше разбить его на отдельное приложение.

Ответ 5

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

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

Ответ 6

"Приложение" может быть много разных вещей, все это действительно сводится к вкусу. Например, скажем, вы строите блог. Ваше приложение может быть всем блогом, или вы можете иметь приложение "admin", приложение "site" для всех общедоступных представлений, приложение "rss", приложение "services", чтобы разработчики могли взаимодействовать с блогом в своих собственные пути и т.д.

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

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

Ответ 7

Два лучших ответа на этот вопрос, которые я нашел в Интернете:

Обсуждение многоразовых приложений (слайды) (видео) также упоминается в других ответах. Беннетт, автор и участник Django, регулярно публикует приложения, которые могут использовать другие, и имеет твердую точку зрения на многие небольшие приложения.
Doordash Советы для Django в Scale, который дает противоположный совет и говорит, что в их случае они перешли на одно приложение после запуска со многими отдельными приложениями. У них возникли проблемы с графиком зависимости миграции между приложениями.

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

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