Стратегия применения Django


14

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

Меня беспокоит то, что в моих приложениях у меня будет несколько вспомогательных методов, которые будут использоваться в разных приложениях. Кроме того, некоторые модели также должны быть доступны для разных приложений. Будет ли это иметь смысл? Это плохо сочетается с разделением задач, которые я надеялся достичь, разделив свое приложение на несколько небольших приложений. Какой будет хороший подход для обмена вспомогательными методами, моделями и т. Д. Между приложениями?

Ответы:


11

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

Смотрите обсуждения ниже для большего количества мыслей по этому вопросу:


Что если приложению необходимо добавить некоторые элементы меню в навигацию проекта? stackoverflow.com/questions/23405610
utapyngo

2

Мне нравится создавать base/приложение без просмотров и моментов для обмена материалами.

Одной из проблем, которая может возникнуть при наличии моделей, распределенных по нескольким приложениям, является циклический импорт. Этого можно избежать, используя строки для ссылки на другие модели ( foo = ForeignKey("someapp.Foo")вместо foo = ForeignKey(someapp.models.Foo)). Django позволяет вам использовать такие строки в других местах.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.