Хотя соблазнительно загружать графы объектов из базы данных, мы обычно стараемся избегать этого, поскольку это означает, что один запрос на элемент и при выборке больших наборов может привести к множеству запросов к базе данных и длительному времени ответа.
Поэтому мы обычно моделируем его таким образом, чтобы член был отделен. Допустим, у вас есть магазин с пользователями. Вместо того, чтобы моделировать пользователей как список в вашем магазине, у вас есть вызов DAO, который гласит «List getUsersForShop (shop)».
Некоторые из наших страниц становятся еще лучше. Для разбитых на страницы веб-страниц нет смысла получать все объекты из базы данных, поскольку они не отображаются одновременно. Таким образом, мы разделили это еще дальше:
Список getUserIdsForShop (магазин)
и затем для каждой строки на странице мы делаем «User getUserForId (long id)».
Это приведет к минимальному потоку данных между сервером, базой данных и клиентом и уменьшит количество вызовов на страницу. Если ваш результат поиска 10.000 пользователей, но вы отображаете только 10 на страницу, вы только что сохранили выборку 99990 пользователей и сохранили их в памяти.
Не используйте это как молоток для всех ваших ногтей. Это просто вариант для больших графов объектов.