Hibernate и JPA, что использовать, где?

Немного истории:

Компоненты Entity Bean были частью EJB 1 и 2. Работать с ними было чертовски сложно, поэтому появилась альтернатива. Потом появился Hibernate. (Я не помню этих времен)

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

JPA - это просто спецификация - она ​​определяет, что должна делать структура ORM и какие аннотации она должна поддерживать. JPA реализуется многими производителями - Hibernate, EclipseLink, OpenJPA и т. Д.

So:

• не используйте Entity beans
• используйте любую реализацию JPA, которая вам нравится. Hibernate - определенно хороший выбор.

Обновление: по поводу вашего второстепенного вопроса в комментариях:

Да, вы можете использовать JPA с EJB Session beans:

@Stateless
public class YourSessionBean implements RemoteInterface {

     @PersistenceContext
     private EntityManager entityManager; // this is the JPA EntityManager
}

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

JPA - это спецификация. Hibernate - это одна из реализаций спецификации. Еще одна реализация - Toplink, но есть и другие.

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

Под entity-компонентом вы подразумеваете entity-компонент EJB 2.x? Это «мертвая» технология, которую оказалось слишком сложно использовать.

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

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

iBatis позволяет писать простые запросы SQL в отдельном файле и сопоставлять их с объектами Java. Благодаря этому код SQL не попадает в ваш Java-код. Вы даете запросам имя и ссылаетесь на это имя в своем коде. Это очень хорошо работает с более крупной устаревшей базой данных, с которой вам необходимо выполнить интеграцию.

Для некоторых простых неформальных запросов такие вещи, как Spring JdbcTemplate, также хорошо работают без когнитивной нагрузки предыдущих фреймворков.

Здесь вы можете найти более подробное представление о вопросе: Презентация JPA и Hibernate

Различия тонкие, и их довольно сложно понять:

1. JPA - это API Java EE для объектно-реляционного сопоставления. У вас должен быть JPA на каждом полноценном сервере приложений Java EE на Земле.
2. Hibernate - это реализация JPA JBoss. Причина, по которой люди часто путают и то, и другое, заключается в том, что JPA в некоторой степени вдохновлен Hibernate.
3. Entity Bean - это просто концепция. Эта концепция означает, что вы будете представлять постоянные сущности вашего решения Java EE с помощью классов Java. I.E. если у вас есть клиенты в вашей системе, вы, вероятно, будете иметь объектный компонент Customer для каждого клиента в вашей базе данных. Вы управляете (создаете, обновляете, удаляете, извлекаете) свои объектные компоненты с помощью JPA. Люди иногда путают Entity Beans со старыми реализациями Entity Beans в Java EE 1.4 и предыдущих версиях. По правде говоря, вы все еще можете иметь Entity Beans с JPA / Hibernate (или JPA / Toplink) на новых серверах приложений Java.

Список некоторых основных поставщиков JPA находится на http://en.wikipedia.org/wiki/Java_Persistence_API в разделе JPA2.

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