Изучаем Java EE 7 - [108]

···

В этом файле тег определяет все метаданные, у которых нет какого-либо эквивалента в виде аннотаций. Тег задает все настройки по умолчанию для единицы сохраняемости, а тег определяет слушателя по умолчанию. В persistence.xml должна иметься ссылка на этот файл, развертывание которого необходимо выполнить с использованием приложения. Тогда DebugListener будет автоматически вызываться для каждой сущности.

Если вы объявите список слушателей сущности по умолчанию, то каждый из них будет вызываться в том порядке, в котором они указаны в файле отображения XML. Слушатели сущности по умолчанию всегда вызываются раньше любых слушателей сущности, определенных в аннотации @EntityListeners. Если потребуется, чтобы для сущности не применялись слушатели по умолчанию, то можно использовать аннотацию @ExcludeDefaultListeners, как показано в листинге 6.44.

Листинг 6.44. Сущность Customer, для которой исключаются слушатели по умолчанию

@ExcludeDefaultListeners
@Entity
public class Customer {
··@Id @GeneratedValue
··private Long id;
··private String firstName;
··private String lastName;
··private String email;
··private String phoneNumber;
··@Temporal(TemporalType.DATE)
··private Date dateOfBirth;
··@Transient
··private Integer age;
··@Temporal(TemporalType.TIMESTAMP)
··private Date creationDate;
··// Конструкторы, геттеры, сеттеры
}

Когда будет инициировано событие, слушатели станут выполняться в следующем порядке.

1. Указанные в @EntityListeners слушатели для определенной сущности или суперкласса в порядке расположения в массиве.

2. Слушатели сущности для суперклассов (в первую очередь станут выполняться те, что располагаются в самом верху списка).

3. Слушатели сущности для сущности.

4. Обратные вызовы суперклассов (в первую очередь будут выполняться те, что располагаются в самом верху списка).

5. Обратные вызовы сущности.

Резюме

Из этой главы вы узнали, как выполнять запросы к сущностям. Менеджер сущностей — это основной инструмент, используемый для взаимодействия с постоянными сущностями. Он может создавать, обновлять сущности, выполнять поиск по идентификатору, удалять и синхронизировать сущности с базой данных с помощью контекста постоянства, который играет роль кэша первого уровня. JPA также сопутствует очень мощный язык запросов JPQL, который не зависит от поставщика базы данных. Вы можете извлекать сущности благодаря богатому синтаксису, задействуя операторы WHERE, ORDER BY или GROUP BY, а при конкурентном доступе к своим сущностям вы будете знать, как использовать контроль версий и когда следует применять оптимистическую или пессимистическую блокировку.

В этой главе также описан жизненный цикл сущности и то, как менеджер сущностей перехватывает события, чтобы запускать методы обратного вызова. Такие методы могут определяться в одной сущности и снабжаться несколькими аннотациями (@PrePersist, @PostPersist и т. д.). Метод также может извлекаться в классы-слушатели и использоваться несколькими или всеми сущностями (с применением слушателей сущностей по умолчанию). Благодаря методам обратного вызова вы понимаете, что сущности не просто анемичные объекты (объекты без бизнес-логики, располагающие только атрибутами, геттерами и сеттерами). Сущности способны включать бизнес-логику, которая может вызываться другими объектами в приложении, либо вызываться автоматически с помощью менеджера сущностей в зависимости от жизненного цикла сущности.

Глава 7. Корпоративные EJB-компоненты

В предыдущей главе было показано, как реализовать постоянные объекты с использованием JPA и как осуществлять к ним запросы с помощью JPQL. Сущности могут включать методы для валидации их атрибутов, однако они не предназначены для решения сложных задач, которые зачастую требуют взаимодействия с другими компонентами (другими постоянными объектами, внешними службами и т. д.). Уровень постоянства не подходит для обработки бизнес-данных. Равно как и интерфейс пользователя не следует применять для выполнения бизнес-логики, особенно когда имеется много интерфейсов (Web, Swing, портативные устройства и т. д.). Для разделения уровня постоянства и уровня представления, обеспечения управления транзакциями и усиления безопасности приложениям необходим бизнес-уровень. В Java EE мы реализуем его с использованием корпоративных EJB-компонентов (Enterprise JavaBeans — EJB).

Разделение на уровни важно для большинства приложений. Придерживаясь восходящего подхода, в предыдущих главах о JPA мы моделировали доменные классы, обычно определяя существительные (Artist, CD, Book, Customer и т. д.). На бизнес-уровне, располагающемся над доменным уровнем, моделируются действия (или глаголы) приложения (создать книгу, купить книгу, распечатать заказ, доставить книгу и т. д.). Этот бизнес-уровень часто взаимодействует с внешними веб-службами (такими как веб-службы SOAP или RESTful), обеспечивает отправку асинхронных сообщений в другие системы (с использованием JMS) или сообщений по электронной почте. Он осуществляет оркестровку компонентов из базы данных во внешние системы и выступает в роли центрального места для ограничения транзакций и безопасности, а также точки входа для клиентов любого типа вроде веб-интерфейсов (сервлетов или EJB-компонентов JSF, являющихся подложками), пакетной обработки или внешних систем. Это логическое разделение сущностей и сессионных EJB-компонентов придерживается парадигмы «разделение ответственности», при использовании которой приложение разбивается на отдельные компоненты. Их функции как можно меньше перекрывают друг друга.