Будьте в спящем режиме и JPA, что использовать, где?
Кто-то мог объяснить мне, что основные отличия между JPA и В спящем режиме?
Где использовать, в спящем режиме?
Где использовать JPA?
Почему не компонент сущности?
6 ответов
Немного истории:
Entity beans были частью EJB 1 и 2. Работа с ними была адской, поэтому требовалась альтернатива. Затем появился Hibernate. (Я не помню этих времен)
Hibernate развивался и стал стандартом де-факто в объектно-реляционном отображении. Затем было решено, что нужен стандарт, и под сильным влиянием Hibernate была создана спецификация JPA.
JPA - это просто спецификация - она определяет, что должна делать ORM-система и какие аннотации она должна поддерживать. JPA реализуется многими производителями - Hibernate, EclipseLink, OpenJPA и т.д.
Поэтому:
- не используйте 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 bean вы подразумеваете EJB 2.x entity bean? Это "мертвая" технология, которая оказалась слишком сложной в использовании.
Я нахожу, что для практических целей все реализации JPA, включая hibernate, чрезвычайно похожи и будут работать для одних и тех же случаев использования. Однако они имеют тенденцию быть немного, эммм...., темпераментными, если они используются для вещей, для которых они не были разработаны.
Поскольку вы, похоже, решаете вопрос о выборе фреймворка персистентности, я хотел бы обратить ваше внимание на то, что есть другие фреймворки, которые очень хорошо работают в других случаях, когда JPA трудно использовать.
iBatis позволяет вам писать простые SQL-запросы в отдельном файле и отображать их на java-объекты. Таким образом, SQL-код не попадает в ваш Java-код. Вы даете запросам имя и ссылаетесь на это имя в своем коде. Это очень хорошо работает с большими унаследованными базами данных, с которыми вам нужно интегрироваться.
Для некоторых простых неформальных запросов такие вещи, как Spring JdbcTemplate, также хорошо работают без когнитивной нагрузки предыдущих фреймворков.
Здесь вы можете найти более глубокое понимание вопроса: JPA & Hibernate presentation
Различия тонкие и довольно сложные для понимания:
- JPA - это API Java EE для объектно-реляционного отображения. Вы должны иметь JPA в каждом сервере приложений Java EE на земле.
- Hibernate - это реализация JPA в JBoss. Причина, по которой люди часто путают оба варианта, заключается в том, что JPA в некоторой степени вдохновлен Hibernate.
- Entity Bean - это просто концепция. Эта концепция означает, что вы будете представлять ваши сущности, хранимые в решении Java EE, с помощью классов Java. Например, если в вашей системе есть клиенты, вы, вероятно, будете иметь Customer entity bean для каждого клиента в вашей базе данных. Вы управляете (создаете, обновляете, удаляете, извлекаете) вашими сущностями-бобами с помощью 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.
Лучше всего принимать собственные решения относительно реализации, поскольку именно вы будете поддерживать ваше приложение, но всегда придерживайтесь функций, основанных на стандартах, а не "аддонов"; вы выиграете в долгосрочной перспективе
.