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

$ mvn integration-test

Резюме

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

В этой главе было показано, что ограничение состоит из аннотации и отдельного класса, реализующего логику валидации. При дальнейшей работе можно агрегировать имеющиеся ограничения для создания новых или переиспользовать уже имеющиеся. Спецификация Bean Validation содержит несколько встроенных ограничений, хотя, к сожалению, некоторых ограничений в ней сильно не хватает (@Email, @URL, @CreditCard).

В первой версии спецификации Bean Validation можно было валидировать только методы и атрибуты. Так обеспечивалось более качественное предметно-ориентированное проектирование, при котором неглубокая доменная валидация помещалась в сам POJO, что позволяло избегать антипаттерна «анемичный объект». В версии Bean Validation 1.1 появилась валидация конструкторов, параметров методов и возвращаемых значений. В настоящее время можно выполнять валидацию предусловий и постусловий, что приближает нас к проектированию по соглашениям.

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

Глава 4. Java Persistence API

Приложения включают бизнес-логику, взаимодействие с другими системами, интерфейсы пользователя… и данные. Большую часть данных, которыми манипулируют наши приложения, приходится хранить в базах данных. Оттуда их требуется извлекать, а также анализировать их. Базы данных имеют важное значение: в них хранятся бизнес-данные, они выступают в качестве центральной точки между приложениями и обрабатывают информацию посредством триггеров или хранимых процедур. Постоянные данные встречаются повсюду, и большую часть времени они используют реляционные базы данных как основной механизм обеспечения постоянства (а не бессхемные базы данных). Информация в реляционных базах данных располагается в таблицах, состоящих из строк и столбцов. Данные идентифицируются с помощью первичных ключей, которые представляют собой особые столбцы с ограничениями уникальности и иногда индексами. Связи между таблицами предполагают использование внешних ключей и таблиц соединения с ограничениями целостности.

В таком объектно-ориентированном языке программирования, как Java, вся эта терминология неактуальна. При использовании Java мы манипулируем объектами, являющимися экземплярами классов. Объекты наследуют от других объектов, располагают ссылками на коллекции прочих объектов, а также иногда указывают на себя рекурсивным образом. У нас есть конкретные классы, абстрактные классы, интерфейсы, перечисления, аннотации, методы, атрибуты и т. д. Объекты хорошо инкапсулируют состояние и поведение, однако это состояние доступно только при работающей виртуальной машине Java (Java Virtual Machine — JVM): если виртуальная машина Java останавливается или сборщик мусора удаляет содержимое ее памяти, объекты исчезают вместе со своим состоянием. Некоторые объекты нуждаются в том, чтобы быть постоянными. Под постоянными данными я имею в виду данные, которые намеренно сохранены на перманентной основе на магнитном носителе, флеш-накопителе и т. п. Объект, который может сохранить свое состояние для его повторного использования позднее, называется постоянным.

Основная идея объектно-реляционного отображения (Object-Relational Mapping — ORM) заключается в объединении миров баз данных и объектов. Это подразумевает делегирование доступа к реляционным базам данных внешним инструментам или фреймворкам, которые, в свою очередь, обеспечивают объектно-ориентированное представление реляционных данных, и наоборот. Инструменты отображения предусматривают двунаправленное соответствие между базой данных и объектами. Несколько фреймворков обеспечивают это, например Hibernate, TopLink и Java Data Objects (JDO), а Java Persistence API (JPA) является предпочтительной технологией и частью Java EE 7.

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

Понятие сущностей

При разговоре об отображении объектов в реляционной базе данных, обеспечении постоянства объектов или выполнении запросов к ним вместо слова «объект» следует использовать термин «сущность». Объекты — это экземпляры, которые располагаются в памяти. Сущности представляют собой объекты, которые недолго располагаются в памяти, но постоянно — в базе данных. Все они могут быть отображены в базе данных. Они также могут быть конкретными или абстрактными; кроме того, они поддерживают наследование, связи и т. д. Произведя отображение этих сущностей, ими можно управлять посредством JPA. Вы можете обеспечить постоянство сущности в базе данных, удалить ее, а также выполнять запросы к этой сущности с использованием языка запросов Java Persistence Query Language, или JPQL. Объектно-реляционное отображение позволяет вам манипулировать сущностями при доступе к базе данных «за кадром». И, как вы увидите, у сущности имеется определенный жизненный цикл. JPA позволяет вам привязывать бизнес-код к событиям жизненного цикла с применением методов обратного вызова и слушателей.