Разница Hibernate 3.5/JPA 2.0
До сих пор я всегда предпочитал использовать Hibernate напрямую, а не JPA 1.0, потому что JPA не хватало некоторых важных функций, которые мне нужны, и Hibernate предоставлял: 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?
Ответы
Ответ 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).
Ответ 2
В EclipseLink Project мы сосредоточили внимание на стратегии, в которой пользователи могут придерживаться JPA как можно больше, и мы работаем над тем, чтобы наши многочисленные расширенные функции легко доступны через расширения, так что вы можете свести к минимуму использование нашего собственного API. Очевидно, что в качестве эталонной реализации JPA мы должны быть совместимыми, но JPA предлагает несколько точек расширения, которые мы используем, включая подсказки запросов и свойства единицы продолжительности. Некоторые функции включены через специальные аннотации EclipseLink JPA и/или eclipselink-orm.xml, а также API, но, как отмечено в JPA 2.0, многие из них могут обрабатываться стандартными конфигурациями.
В конечном итоге преимущество заключается в том, что, оставаясь со стандартом как можно больше, вы можете использовать общую базу знаний, а также инструменты и интеграцию. Расширенные возможности ORM также очень важны, но их необходимо использовать только в расширенных случаях, и использование должно быть хорошо изолировано с минимальной связью.
Дуга
