Весенние данные JPA: Дизайн вложенных объектов - однонаправленный? двунаправленная?

Question

Скажем, у меня есть вложенные объекты, например:

 
Customer
 
    Project
 
     Rent
 
     Fault
 
(and maybe deeper) 

Клиент содержит права пользователя, я должен проверить. Тогда есть способ обновить ошибку:

void updateFault(long faultId, String content, User user) { .. } 

Вопрос: Как получить от вины к клиенту?

1. Опция: Использование обратной ссылки на родитель: Вина сдать, снять, проект Заказчика
2. Опция: Использование обратной ссылки от Fault Заказчика (а также от продажи клиента и т.д.)

3. Опции: Отсутствие обратной связи и увеличение количества запросов к базе данных, таких как

   rent = rentRepository.findByFault (fault);

   проект = проектRepository.findByRent (аренда);

   клиент = клиентRepository.findByProject (проект);

Я прочитал, что мне следует избегать двунаправленной ссылки. Но что, если у меня 20 уровней и много данных? Тогда вариант № 3 не подходит вообще.

Я использую Spring Data JPA в проекте Spring MVC.

Answer 1

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

1. Нет обратной ссылки и идти вверх по одной присоединиться

2. изменения ваша модель, чтобы те обратные ссылки, о которых идет речь, стали основными ссылками.

Давайте посмотрим на свойства различных подходов

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

2. Прямые обратные ссылки: Как только у вас есть это, я думаю, что это всего лишь вопрос времени, пока вы не получите ссылки на проект и аренду. Также это создает циклические зависимости между классами, которые в противном случае не связаны напрямую. Вместе это оставляет вас (IMHO) с запутанным беспорядком.

3. Каскад запросов к базе данных Это будет очень медленно. Единственный сценарий, когда я буду делать это, - это когда у меня есть модель, которая действительно хорошо подходит для всех моих других требований, и мне нужна эта конструкция только в очень редких ситуациях, где производительность не имеет значения.

4. Прямая ссылка: По сравнению с прямыми обратными ссылками, это не создает клубок зависимости на стороне java. Вам придется писать пользовательские запросы, но они должны быть прямолинейными. Звучит как разумное решение для меня.

5. возвращаются ссылки в модели (я краду очки от @Oliver Гирке здесь): С вашим текущим модельным подходом вы легко в конечном итоге с одной организацией, которая имеет отношение ко всему остальному имеет. Если ваш домен не является тривиальным, это станет грязным. Если у вас отношение 1: N, это очень часто означает, что сторона N может быть нулевой/пустой, поэтому она действительно необязательна. Также вам очень нужны только подмножества. Как и все незавершенные проекты, или все проекты, которые отстают от графика. Поэтому во многих случаях имеет смысл моделировать ссылку в противоположном направлении. И если вам нужно ориентироваться в исходном направлении, используйте для этого репозиторий.