Различие в спящем режиме 3.5 / JPA 2.0
До сих пор я всегда предпочитал использовать, в спящем режиме непосредственно, а не JPA 1.0, потому что JPA испытывал недостаток в некоторых важных функциях, в которых я нуждался, и Будьте в спящем режиме предоставленные: Критерии API, второй кэш уровня, однонаправленный OneToMany и немногие другие.
Теперь, с появлением JPA 2.0 и всех новых возможностей, которые идут с ним и которые первоначально отсутствовали в (http://en.wikibooks.org/wiki/Java_Persistence/What_is_new_in_JPA_2.0%3F) JPA 1.0, интересно, существует ли все еще потребность использовать, в спящем режиме непосредственно.
Каково твое мнение? Что оставлено внутри, в спящем режиме 3.5, что я не могу сделать с JPA 2.0?
2 ответа
Теперь, с появлением 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, "Расширения аннотаций Hibernate" для большего количества "примеров".
Но позвольте мне настоять, я рекомендую использовать JPA там, где вы можете, Hibernate там, где вы должны (последняя часть становится тоньше с JPA 2.0).
В проекте EclipseLink мы сосредоточились на стратегии, при которой пользователи могут максимально придерживаться JPA, и мы работали над тем, чтобы наши многие расширенные функции были легко доступны через расширения, чтобы вы могли минимизировать использование вами нашего собственного API. Очевидно, что в качестве эталонной реализации JPA мы должны быть совместимыми, но JPA предлагает несколько точек расширения, которые мы используем, включая подсказки запросов и свойства единиц сохраняемости. Некоторые функции включаются через аннотации EclipseLink для JPA и / или eclipselink-orm.xml, а также через API, но, как отмечено в JPA 2.0, многие из них могут обрабатываться в стандартных конфигурациях.
В конечном итоге преимущество состоит в том, что, максимально придерживаясь стандарта, вы можете использовать общую базу знаний, а также инструменты и интеграции. Расширенные возможности ORM также очень важны, но должны потребоваться только в сложных случаях, а использование должно быть хорошо изолировано с минимальной связью.
Дуг