Организация кода django-проекта, связывание приложений?

Question

[FeNUMe]

Стало вот интересно кто как организует свои джанго проекты:

создаете несколько приложений(по одному для логических разделов аля блог, контакты, новости итд) и в каждом отдельно создаете модели и вьюхи;

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

другие варианты;?

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



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

Answer 1

[Марк]

По-хорошему приложение в django — юниксвей в чистом виде: делает что-то одно, делает это хорошо, обладает неким внешним API для взаимодействия с другими модулями. Обычно даже в небольшом проекте насчитывается около десятка приложений. Плюсы такого подхода — значительно легче тестировать, повторно использовать код, можно сравнительно безболезненно менять имплементацию модуля, не нарушая работу всего сайта.

Антипаттерн — монолитные приложения (обычно буквально одно-два). Их, помимо прочего, тяжелее поддерживать, поскольку код выполняет множество не связанных напрямую задач (функции, отвечающие за генерацию RSS и смену аватарки пользователя, находятся рядом — в таком файле ничего не получится сделать без поллитры и ctrl-F). Это особенно актуально, когда в команду добавляется новый разработчик.

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

Answer 2

[Константин Китманов]

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

Comments

[FeNUMe]

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

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

[Константин Китманов]

в любом случае вы можете использовать Inversion of Control, Dependency Injection, Observer-Listener и прочие паттерны увеличения ортогональности в вертикально связанных системах. Или вот еще AOP — очень удобно для сквознрй функциональности.

Answer 3

[Евгений]

У меня большое и старое приложение на Django. Используется баланс между двумя этими подходами: большая часть функциональности в одном большом приложении, разбита в пакетах по модулям, типа:
— big_app
— models
— profile.py
— content.py
— events.py
— forum.py
— views
— forum.py
— event.py

Часть вынесена в отдельные приложения, не понимаю зачем, ибо они все равно не могут использоваться повторно, так как слишком завязаны на специфику приложения и используют импорты из главного приложения. Но не я создавал эту структуру. Я бы, наверное, вместо этого добавлял бы модули в существующее большое приложение, а в отдельные приложения выносил бы только код, который можно использовать повторно (такого у нас немного, но есть).

Comments

[Евгений]

Извините за съехавшее форматирование структуры, надо было preview нажать перед публикацией. :(

Answer 4

[mineevburyat]

Хорошей практикой будет создать дополнительную модель, которая объединит интересные вам модели. Например есть три независимых приложения: Блог, Библиотека и полезные ссылки, которые по отдельности выполняют функционал хорошо, с категориями метками, актуальностью и пр.
Требуется связать блог с несколькими полезными ссылками и несколькими полезными книгами.
Тогда лучше создать модель которая связывает пост блога как один к одному, а полезные ссылки и книги как один ко многим с возможностью пустого поля. И вуаля. Статья может быть связана или не связана с несколькими книгами и полезными ссылками.