У меня есть постоянный уровень, который обслуживает данные для многих клиентов.У меня также есть нормализованная структура таблиц, что означает, что значения распределены по таблицам.Я хочу разработать свою службу персистентности так, чтобы службы, зависящие от нее, выполняли минимальные поездки туда и обратно: не более одной, если это возможно.
Учитывая это, на чем я должен сосредоточиться для элегантного решения?
1. Я гарантирую, что клиенты могут указать ту часть графа объектов, которую они хотят во время выборки?(тем самым сокращая количество поездок в оба конца) [например: fetch(parent, list<child-object-name>)
]
2. Я гарантирую, что я предоставляю общие методы, такие как увлажнение частей объекта, наряду с основными извлечениями?[например: hydrate(parent, list<child-table-name>)
]
3. Предоставляю ли я базовую информацию для начала (например, объектный граф до объектов только для глубины 1 / только для таблиц просмотра), а остальные только по запросу?
Насколько я понимаю, в сети много дискуссий с очень хорошей информацией.Я также прочитал несколько:
* http://forum.springsource.org/archive/index.php/t-23439.html
* Как я могу получить доступ к загруженным ленивым полям после закрытия сессии, используя hibernate? (ответ Пола Адамсона)
* Глубокие графы объектов Hibernate
однако большинство ответов на вопрос о том, «делай то, что тебе больше нравится».Что обычно делают программисты в этой ситуации?