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

Question

В документации Hibernate EntityManager указано , что:

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

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

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

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

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

Answer 1

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

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

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

Это происходит начиная с JPA 1.0, разработчики Hibernate создали Hibernate3 с "JPA в уме" и приняли семантику JPA, значения по умолчанию и т. Д. В Hibernate3. Возможно, вы захотите послушать Гэвина в этом Tech Talk: Гэвин Кинг на 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).

Похожие вопросы

• Разница Hibernate 3.5 / JPA 2.0

Answer 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's @ Embeddable
• Коллекция @Embeddables @ ElementCollection

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

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

Answer 3

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

Меня не очень интересует использование вторичного уровня для доступа к функциональности ядра Hibernate.Что касается переносимости на уровне постоянства, то это полная не проблема .

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

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

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

Answer 4

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

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