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

Question

До сих пор я всегда предпочитал использовать Hibernate напрямую, а не JPA 1.0, потому что JPA не хватало некоторых важных функций, которые мне были нужны, и Hibernate предоставлял: Criteria API, кэш второго уровня, однонаправленный OneToMany и некоторые другие.

Теперь, с появлением JPA 2.0 и всех новых функций, которые идут с ним и которые изначально отсутствовали в JPA 1.0 (http://en.wikibooks.org/wiki/Java_Persistence/What_is_new_in_JPA_2.0%3F),), мне интересно, есть ли еще необходимость использовать Hibernate напрямую.

Каково ваше мнение? Что осталось в Hibernate 3.5, что я не могу сделать с JPA 2.0?

Answer 1

Теперь, с появлением JPA 2.0 и всех новых функций, которые идут с ним и которые изначально отсутствовали в JPA 1.0 (http://en.wikibooks.org/wiki/Java_Persistence/What_is_new_in_JPA_2.0%3F),, мне интересно, есть ли еще необходимость использовать Hibernate напрямую.

Даже для JPA 1.0 я бы порекомендовал другой подход: «JPA, где вы можете, Hibernate, где вы должны».

Каково ваше мнение? Что осталось в Hibernate 3.5, что я не могу сделать с JPA 2.0?

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

Но в некоторых ситуациях вам все еще могут понадобиться некоторые специфические расширения Hibernate: пользовательский UserType, нестандартный генератор, запрос на примере, @Formula, @Index и т. Д. Посмотрите на Раздел 2.4, «Расширения аннотаций в спящем режиме» для получения дополнительных «примеров».

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

Answer 2

В EclipseLink Project мы сосредоточены на стратегии, в которой пользователи могут максимально использовать JPA, и мы работаем над тем, чтобы сделать наши многочисленные расширенные функции легкодоступными с помощью расширений, чтобы вы могли минимизироватьвы используете наш родной API.Очевидно, что в качестве эталонной реализации JPA мы должны быть совместимыми, но JPA предлагает несколько точек расширения, которые мы используем, включая подсказки запросов и свойства единиц персистентности.Некоторые функции включаются посредством специальных аннотаций EclipseLink JPA и / или eclipselink-orm.xml, а также API, но, как отмечено в JPA 2.0, многие из них могут обрабатываться стандартными конфигурациями.

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

Doug