Изучаем Java EE 7

·············xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"

·············xsi: schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 

·············http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"

·············version="2.1">

··

····org.eclipse.persistence.jpa.PersistenceProvider

····org.agoncal.book.javaee7.chapter04.Book

····

······

value="drop-and-create"/>

······

······

················value="org.apache.derby.jdbc.ClientDriver"/>

······

················value="jdbc: derby://localhost:1527/chapter04DB;create=true"/>

······

······

····

··

Единица сохраняемости chapter04PU определяет JDBC-подключение для базы данных Derby chapter04DB, которая функционирует на локальном хосте с помощью порта 1527. К ней подключается пользователь (APP) с применением пароля (APP) по заданному URL-адресу. Тег дает указание поставщику постоянства управлять классом Book (существуют и другие теги для неявного или явного обозначения классов с управляемым постоянством, например , или ). Без единицы сохраняемости сущностями можно манипулировать как POJO, однако их постоянство при этом обеспечиваться не будет.

Жизненный цикл сущности и обратные вызовы

Сущности представляют собой всего лишь POJO. Когда EntityManager управляет POJO, у них имеется идентификатор постоянства (ключ, который уникально идентифицирует экземпляр и является эквивалентом первичного ключа), а база данных синхронизирует их состояние. Когда управление ими не осуществляется (то есть они обособлены от EntityManager), их можно использовать как любой другой Java-класс. Это означает, что у сущностей имеется жизненный цикл (рис. 4.3). Когда вы создадите экземпляр сущности Book с помощью оператора new, объект будет располагаться в памяти, а JPA ничего не будет знать о нем (этот объект даже может перестать существовать в результате сборки мусора) Когда им начнет управлять EntityManager, таблица BOOK отобразит и синхронизирует его состояние. Вызов метода EntityManager.remove() приведет к удалению соответствующей информации из базы данных, однако Java-объект продолжит находиться в памяти, пока не исчезнет в результате сборки мусора.

Рис. 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 в отношении сущности.