it-swarm-ru.tech

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

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

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

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

85
Håkan

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

39
Antti Rasinen

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

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

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

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

18
blahspam

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

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

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

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

Слайд: Reusable_apps.pdf

Снято с горки

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

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

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

11
Yeo

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

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

5
Ryan

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

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

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

1
willurd

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

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

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

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