Любые недостатки использования Hibernate EntityManager (против Hibernate Core)?

Документация Hibernate EntityManager указывает, что:

Вы можете использовать комбинацию всех трех вместе, аннотации без JPA   программные интерфейсы и жизненный цикл, или даже чистые родные Hibernate Core,   в зависимости от деловых и технических потребностей вашего проекта. Вы можете на   все время возвращаются к родным API Hibernate или, если требуется, даже для   родной JDBC и SQL.

Код, который использует API JPA (EntityManager), явно более портативен (даже при случайных отказах от Hibernate Core).

Но были ли у меня какие-то преимущества при использовании исключительно Hibernate Core? Интересно, если модель JPA 2 действительно подходит на вершине Hibernate Core без каких-либо противоречий? IOW, является ли резервное копирование Core всегда легким и без проблем?

Моя главная проблема заключается в следующем:

Возможно, отличия не только в API, но и в базовой семантике?! (например, различные конфликты между транзакциями/версией/блокировкой, которые могут конфликтовать: пессимистическая блокировка упоминается в документации Core, но не в документации EntityManager - так что я могу использовать пессимистическую блокировку, возвращаясь к Core без каких-либо проблем?.)

ОТВЕТЫ

Ответ 1

Но были ли у меня какие-то преимущества при использовании чисто Hibernate Core?

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

Интересно, если модель JPA 2 действительно подходит на вершине Hibernate Core без каких-либо противоречий?

Начиная с JPA 1.0, разработчики Hibernate создали Hibernate3 с учетом "JPA" и приняли семантику JPA, значения по умолчанию и т.д. в Hibernate3. Возможно, вы захотите послушать Gavin в этом Tech Talk: Gavin King на Hibernate3 и EJB3:

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

  • Новые функции Hibernate3
  • Связь между Hibernate3 и контейнером EJB3 в JBoss
  • Что отличает Hibernate3 от спецификации EJB3.
  • Пользовательские аннотации Hibernate доступны вне EJB
  • Будущее Hibernate

И согласно моему практическому опыту, факт, что Hibernate не противоречит EJB 3, истинно.

IOW, является ли резервное копирование Core всегда легким и без проблем?

Если вы используете Core напрямую или нет, вы используете его (EntityManager является оберткой вокруг Session). Итак, да, возвращение к Core очень просто, если вам действительно нужно (для вещей, которые еще не находятся в спецификации, например Query By Example). И нет, это не вызовет никаких проблем (поскольку вы на самом деле используете его или его подмножество в JPA).

Связанные вопросы

Ответ 2

Было ясно: в зависимости от деловых и технических потребностей вашего проекта

Но были ли у меня какие-то преимущества при использовании чисто Hibernate Core?

Не забывайте, что аннотации Hibernate и Hibernate EntityManager построены поверх ядра Hibernate. Итак, еще один слой. Помимо этого, он полагается на свои метаданные отображения, хранящиеся в XML файлах. Некоторые пользователи предпочитают использовать XML файлы вместо аннотаций, поскольку они оставляют объекты домена полностью независимыми от выбранной вами реализации DAO. Но при использовании аннотаций, Hibernate с JPA-книгой ясно

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

JDBC >> Hibernate core >> Hibernate Annotations

...

JDBC >> Hibernate core >> Hibernate EntityManager

И JPA 2 лучше подходит для того, что не было предоставлено JPA 1. Теперь доступно множество новых функций, таких как

  • API объектно-ориентированного запроса
  • Wrapper @Embeddable
  • Коллекция @Embeddables @ElementCollection

И так далее...

Не забывайте, что JPA EntityManager позволяет получить базовый поставщик, зависящий от поставщика, с помощью метода getDelegate, если вам нужны функции, в которых JPA не предоставляют.

Ответ 3

Мне нравится напрямую использовать Hibernate Core. Я также предпочитаю файлы сопоставления XML.

Мне неинтересно использовать дополнительный уровень, чтобы получить доступ к функциональным возможностям ядра Hibernate. Насколько я заинтересован в переносимости в уровне сохранения, это полная не-проблема.

Существует очень мало реальных преимуществ API JPA по сравнению с Hibernate API - я видел людей, использующих JPA с запросами (где критерии, вероятно, были бы более ясными и лучшими), а аннотации JPA несколько лучше разработаны.

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

Переносимость базы данных OTOH очень реальна. У меня есть пользовательские распределители (генераторы), которые я использую, которые полностью переносимы и намного более эффективны и проще, чем сумасшедший беспорядок, который является неправильно спроектированным спящим.

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

Ответ 4

Преимущества использования JPA api намного превосходят любые недостатки использования чистого спящего режима. Я не эксперт, но я не знаю ни о каких ситуациях, когда было бы полезно спуститься в спящий режим. (Сбрасывание, чтобы сделать чистый JDBC - это другое дело.)

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