Когда создавать новое приложение (с помощью Startapp) в Django? - PullRequest
85 голосов
/ 15 сентября 2008

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

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

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

Ответы [ 7 ]

40 голосов
/ 15 сентября 2008

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

18 голосов
/ 15 сентября 2008

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

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

Мой общий подход заключается в объединении определенных функций или наборов функций в «приложения», как если бы я собирался выпустить их публично. Сложная часть здесь - выяснить, насколько велика каждая корзина.

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

12 голосов
/ 07 ноября 2011

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

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

Слайд: Reusable_apps.pdf

Взято со слайда

Это должно быть собственное приложение?

  • Это совершенно не связано с фокусом приложения?
  • Это ортогонально тому, что я делаю?
  • Будут ли мне нужны аналогичные функции на других сайтах?

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

11 голосов
/ 15 сентября 2008

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

  • Профили пользователей
  • Сообщения на форуме
  • Сообщения блога
5 голосов
/ 16 сентября 2008

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

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

1 голос
/ 12 декабря 2018

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

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...