спящий режим, лениться или не лениться?

У меня есть entity A, который имеет отношение "многие ко многим" с entity B.

Итак, макет таблицы: A, AB(mapping table), B

Чтобы получить объект сущности A: я вызываю A.getById(), который делает getHibernateTemplate().get(A.class, id), используя spring и hibernate.

Проблема в том, что иногда последующему коду просто требуется A, иногда последующий код будет продолжать обращаться к связанным B, поэтому мы хотели бы использовать ленивую загрузку в некоторых случаях и нетерпеливо в некоторых других случаях. но проблема в том, что весь доступ к базе данных осуществляется через один и тот же ADao.java, поэтому есть только один метод getById().

Следует ли мне создать две версии метода getById ()?

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

каково ваше мнение об этом выборе?

Спасибо


hibernate design-patterns lazy-evaluation
person teddy teddy    schedule 13.12.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Общие соображения можно найти в документации Hibernate 3.6 о стратегии получения. Стратегия выборки по умолчанию определяется в аннотациях сопоставления или в файле hbm.xml. Есть три способа динамического переключения со стратегии отложенной загрузки по умолчанию на стратегию быстрой загрузки. Первые два требуют отдельных реализаций методов DAO для сценариев использования отложенной и активной загрузки:

  1. Criteria.setFetchMode() в запросе критериев гибернации
  2. FETCH ключевое слово в запросе HQL
  3. Начиная с Hibernate 3.5 (сейчас не совсем уверен, может быть, 3.6) есть третий вариант использования получить профили для динамического переключения с отложенной загрузки на активную загрузку.

Профиль выборки включен / отключен в области сеанса. Таким образом, при условии, что в текущем сеансе установлен желаемый профиль выборки, вы можете использовать один и тот же метод DAO как для отложенной загрузки, так и для варианта использования с нетерпеливой загрузкой.

Здесь важно знать, что вы можете переключиться только со стратегии отложенной загрузки, определенной в аннотациях или в файле hbm.xml , на стратегию активной загрузки. а не наоборот. Это ограничение не зависит от метода переключения стратегии выборки.

person tscho    schedule 13.12.2011
comment
FetchProfile великолепен. Есть ли аналог для обновления? - person Tadhg; 06.06.2017

arrow_upward
3
arrow_downward

Что ж, вы правильно описали проблему. Это просто компромисс между простотой (всего один метод) и производительностью (два метода, каждый из которых возвращает именно то, что необходимо). Если время отклика правильное, просто используя единственный метод и ленивую загрузку B, то ничего не трогайте. Если время отклика слишком велико, и вы измерили эту нетерпеливую загрузку, она исправила бы ее, тогда введите новый метод.

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

Кроме того, загрузка двух ассоциаций toMany довольно редка: обычно показываются все продукты категории на странице, но редко показываются все покупки всех продуктов категории.

person JB Nizet    schedule 13.12.2011