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

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

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

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

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

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

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

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

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

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

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

Слайд: Reusable_apps.pdf

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

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

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

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

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

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

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

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

Я нашел два лучших ответа на этот вопрос в Интернете:

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

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

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

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

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

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