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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слайд: Reusable_apps.pdf

Taken from the slide

Should this be its own application?

• Is it completely unrelated to the app’s focus?
• Is it orthogonal to whatever else I’m doing?
• Will I need similar functionality on other sites?

If any of them is "Yes"? Then best to break it into a separate application.

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

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

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

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

Лучший ответ на этот вопрос дает Эндрю Годвин (разработчик ядра Django):

На мой взгляд, основная цель приложений - обеспечить логическое разделение повторно используемых компонентов - в частности, первоклассное пространство имен для models / admin / и т. д. - и предоставить простой способ «включить» или «выключить».

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

Есть ли что-то конкретное, что, по вашему мнению, можно отделить от концепции приложения сегодня? Он нужен моделям и администраторам для автообнаружения и уникального префикса пространства имен, поэтому его трудно отменить, и я изо всех сил пытаюсь придумать другие функции, для которых он вам нужен (на самом деле, если все, что вам нужно, это просто библиотека, вы можете сделать это обычный Python - нет необходимости в упаковке приложения, если вы не отправляете модели, шаблоны или код администратора IIRC)