Проблема дизайна или как решить циклическую зависимость?

Question

[Джанго Всемогущий]

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

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

Для каждой модели создается репозиторий.
Репозиторий пользователя зависит от репозитория подразделения.
Репозиторий подразделения зависит от репозитория пользователя.

Как решается данная ситуация? Можно в примерах с кодом

Comments

[Василий Банников]

Нужно понять, почему возникла циклическая зависимость. Обычно это можно решить введением нового класса.

[Джанго Всемогущий]

Василий Банников, с точки зрения архитектуры, почему такое происходит. Я привел пример с циклической зависимостью.

[Василий Банников]

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

[soloveid]

Дизайн прост и понятен.

Ну давай глянем.

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

Очень странно. Уже неправильно. Потом вы в кользователя засунете дом и машину? Нельзя засовывать в него
это, это ошибка.

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

Ну ок.

Репозиторий пользователя зависит от репозитория подразделения.

Если уберёте зависимость, на которую я указал выше, то тут не будет зависимости.

Репозиторий подразделения зависит от репозитория пользователя.

Норм, логично.

Так что просто уберите вашу первую зависимость и будет всё ок.

Answer 1

[cicatrix]

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