Как избежать циклических зависимостей в приложениях Django

Работая над своими проектами на основе Django, я всегда стараюсь следовать подходу Django к многоразовым приложениям — я пытаюсь отделить свои приложения друг от друга и особенно стараюсь избегать перекрестных ссылок, но иногда это кажется невозможным.

Рассмотрим простой пример с 2 приложениями: статьи и пользователи. Приложение «Статьи» определяет модель статьи, представление списка статей и представление одной статьи, приложение «Пользователи» определяет модель пользователя и представление профиля пользователя. Статья ссылается на пользователя из поля автора, поэтому применение статей, очевидно, зависит от приложения пользователя, и это нормально.

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

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

Ребята, что вы делаете в таких случаях?


django architecture circular-dependency
person Alexander Finn    schedule 23.01.2011    source источник

Ответы (3)


arrow_upward
10
arrow_downward

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

Стоит ли этот уровень развязки, я не знаю. Иногда программирование для повторного использования в первую очередь мешает сделать вещь пригодной для использования.

person Spacedman    schedule 23.01.2011
comment
люблю это предложение. Иногда программирование для повторного использования мешает сделать вещь пригодной для использования в первую очередь. +1 - person Sripathi Krishnan; 15.01.2016

arrow_upward
1
arrow_downward

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

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

person Tomasz Zieliński    schedule 24.01.2011

arrow_upward
-1
arrow_downward

Похоже, что в данном случае зависимость пользователей от статей заключается в методе, а не в поле. (Неважно, будет ли это метод модели, метод класса модели или метод менеджера). Если это так, вы можете сделать ленивый импорт статей внутри метода. К моменту выполнения этого импорта user.models будут полностью загружены, так что даже если это циклический импорт, он не вызовет проблем. Оператор «импортировать пользователей» в статьях не должен перезагружать пользователей и будет иметь доступное полное пространство имен пользователей.

person Jameson Quinn    schedule 24.06.2011