Изучаем Java EE 7 - [55]
Рис. 4.3. Жизненный цикл сущности
Операции с сущностями подпадают под четыре категории: обеспечение постоянства, обновление, удаление и загрузка — аналогичные категориям операций с базами данных, к которым относятся соответственно вставка, обновление, удаление и выборка. Для каждой операции имеют место события с приставками pre и post (за исключением загрузки, для которой имеет место только событие с приставкой post). Эти события могут быть перехвачены EntityManager для вызова бизнес-метода. Как вы увидите в главе 6, в вашем распоряжении будут аннотации @PrePersist, @PostPersist и т. д. JPA позволяет вам привязывать бизнес-логику к определенной сущности, когда имеют место эти события. Упомянутые аннотации могут быть применены к методам сущностей (также известным как методы обратного вызова) или внешним классам (также известным как слушатели). Вы можете представлять себе методы обратного вызова и слушатели как аналогичные триггеры в реляционной базе данных.
Интеграция с Bean Validation
Технология Bean Validation, которая была разъяснена в предыдущей главе, связана с Java EE несколькими способами. Один из них выражается в ее интеграции с JPA и жизненным циклом сущностей. Сущности могут включать ограничения Bean Validation и автоматически подвергаться валидации. Фактически автоматическая валидация обеспечивается благодаря тому, что JPA возлагает ее проведение на реализацию Bean Validation при наступлении событий жизненного цикла сущности pre-persist, pre-update и pre-remove. Разумеется, при необходимости валидация по-прежнему может проводиться вручную вызовом метода validate класса Validator в отношении сущности.
В листинге 4.6 показана сущность Book с двумя ограничениями Bean Validation (@NotNull и @Size). Если значением атрибута title окажется null, а вы захотите обеспечить постоянство этой сущности (вызвав EntityManager.persist()), то во время выполнения JPA будет выброшено исключение ConstraintViolation, а соответствующая информация не будет помещена в базу данных.
>@Entity
>public class Book {
>··@Id @GeneratedValue
>··private Long id;
>··@NotNull
>··private String title;
>··private Float price;
>··@Size(min = 10, max = 2000)
>··private String description;
>··private String isbn;
>··private Integer nbOfPage;
>··private Boolean illustrations;
>// Конструкторы, геттеры, сеттеры
>}
Обзор спецификации JPA
Версия JPA 1.0 была создана вместе с Java EE 5 для решения проблемы обеспечения постоянства данных. Она объединила объектно-ориентированные и реляционные модели. В Java EE 7 версия JPA 2.1 идет тем же путем простоты и надежности, привнося при этом новую функциональность. Вы можете использовать этот API-интерфейс для доступа к реляционным данным Enterprise JavaBeans, веб-компонентам и приложениям Java SE и манипулирования ими.
JPA — это абстракция над JDBC, которая дает возможность быть независимым от SQL. Все классы и аннотации этого API-интерфейса располагаются в пакете javax.persistence. Рассмотрим основные компоненты JPA.
• Объектно-реляционное отображение, которое представляет собой механизм отображения объектов в данные, хранящиеся в реляционной базе данных.
• API менеджера сущностей для осуществления операций, связанных с базами данных, например CRUD-операций.
• JPQL, который позволяет вам извлекать данные с помощью объектно-ориентированного языка запросов.
• Транзакции и механизмы блокировки, которые предусматривает Java Transaction API (JTA) при одновременном доступе к данным. JPA также поддерживает ресурсные локальные (не-JTA) транзакции.
• Обратные вызовы и слушатели для добавления бизнес-логики в жизненный цикл того или иного постоянного объекта.
Краткая история JPA
Решения, которые позволяют выполнять объектно-реляционное отображение, существуют уже долгое время, причем они появились раньше Java. Продукты вроде TopLink начинали со Smalltalk в 1994 году, перед тем как перейти на Java. Коммерческие продукты для выполнения объектно-реляционного отображения, например TopLink, доступны с самых первых дней существования языка Java. Они стали успешными, но никогда не были стандартизированы для платформы Java. Схожий подход к объектно-реляционному отображению был стандартизирован в форме технологии JDO, которой так и не удалось значительно проникнуть на рынок.
В 1998 году появилась версия EJB 1.0, которая позднее сопутствовала J2EE 1.2. Это был тяжеловесный, распределенный компонент, использовавшийся для обработки транзакционной бизнес-логики. Технология Entity Bean CMP, представленная в EJB 1.0 как опциональная, стала обязательной в EJB 1.1 и совершенствовалась с выходом последующих версий вплоть до EJB 2.1 (J2EE 1.4). Постоянство могло обеспечиваться только внутри контейнера благодаря сложному механизму создания экземпляров с использованием домашних, локальных или удаленных интерфейсов. Возможности в плане объектно-реляционного отображения тоже оказались весьма ограниченными, поскольку наследование было сложно отображать.
Параллельно с миром J2EE существовало популярное решение с открытым исходным кодом, которое привело к удивительным изменениям в «направлении» постоянства: имеется в виду технология Hibernate, вернувшая назад легковесную, объектно-ориентированную постоянную модель.
