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

Как показано на рис. 4.1, сущность Book отображается в таблице BOOK, а каждому столбцу присваивается имя в соответствии с именем атрибута класса (например, атрибут isbn, имеющий тип String, отображается в столбец, который имеет имя ISBN и тип VARCHAR). Эти правила отображения по умолчанию являются важной частью принципа, известного как конфигурация в порядке исключения.

Рис. 4.1. Синхронизация данных между сущностью и таблицей

В версии Java EE 5 была представлена идея конфигурации в порядке исключения (иногда называемая программированием в порядке исключения или соглашением прежде конфигурации), которая по-прежнему активно используется сегодня в Java EE 7. Это означает, что, если не указано иное, контейнер или поставщик должен применять правила по умолчанию. Другими словами, необходимость обеспечения конфигурации является исключением из правила. Это позволяет вам написать минимальное количество кода для того, чтобы ваше приложение работало, положившись на правила, применяемые контейнером и поставщиком по умолчанию. Если вы не хотите, чтобы поставщик применял правила по умолчанию, то можете настроить отображение в соответствии со своими нуждами. Иначе говоря, необходимость обеспечения конфигурации является исключением из правила.

Без аннотаций сущность Book в листинге 4.1 рассматривалась бы как простой POJO, а ее постоянство не обеспечивалось бы. Это закон: если не предусмотрено никакой специальной конфигурации, то должны применяться правила по умолчанию, а поставщик постоянства по умолчанию исходит из того, что у класса Book нет представления базы данных. Но, поскольку вам необходимо изменить это поведение по умолчанию, вы снабжаете класс аннотацией @Entity. То же самое и в случае с идентификатором. Вам нужен способ сообщить поставщику постоянства о том, что атрибут id требуется отобразить в первичный ключ, поэтому вы снабжаете его аннотацией @Id, а значение соответствующего идентификатора автоматически генерируется поставщиком постоянства с использованием опциональной аннотации @GeneratedValue. Решение такого рода характеризует подход «конфигурация в порядке исключения», при котором аннотации не требуются в более общих случаях, а используются, только когда необходимо переопределение. Это означает, что по отношению ко всем прочим атрибутам будут применяться следующие правила отображения по умолчанию.

• Имя сущности будет отображаться в имя реляционной таблицы (например, сущность Book отобразится в таблицу BOOK). Если вы захотите отобразить сущность в другую таблицу, то вам потребуется прибегнуть к аннотации @Table, как вы увидите в разделе «Элементарное отображение» в следующей главе.

• Имена атрибутов будут отображаться в имени столбца (например, атрибут id или метод getId() отобразится в столбце ID). Если вы захотите изменить это отображение по умолчанию, то вам придется воспользоваться аннотацией @Column.

• Правила JDBC применяются при отображении Java-примитивов в типах реляционных данных. String отобразится в VARCHAR, Long — в BIGINT, Boolean — в SMALLINT и т. д. Размер по умолчанию столбца, отображаемого из String, будет равен 255 (String отобразится в VARCHAR(255)). Однако имейте в виду, что правила отображения по умолчанию разнятся от одной базы данных к другой. Например, String отображается в VARCHAR при использовании базы данных Derby и в VARCHAR2, если применяется Oracle. Integer отображается в INTEGER в случае с базой данных Derby и в NUMBER при использовании Oracle. Информация, касающаяся основной базы данных, будет содержаться в файле persistence.xml, который вы увидите позднее.

Придерживаясь этих правил, сущность Book будет отображена в Derby-таблицу со структурой, описанной в листинге 4.2.

Листинг 4.2. Сценарий для создания структуры таблицы BOOK

CREATE TABLE BOOK (
··ID BIGINT NOT NULL,
··TITLE VARCHAR(255),
··PRICE FLOAT,
··DESCRIPTION VARCHAR(255),
··ISBN VARCHAR(255),
··NBOFPAGE INTEGER,
··ILLUSTRATIONS SMALLINT DEFAULT 0,
··PRIMARY KEY (ID)
)

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

В листинге 4.1 приведен пример очень простого отображения. Как вы увидите в следующей главе, отображение может быть намного более обширным, включая всевозможные вещи, начиная с объектов и заканчивая связями. Мир объектно-ориентированного программирования изобилует классами и ассоциациями между классами (и коллекциями классов). В случае с базами данных также моделируются связи, но по-другому — с использованием внешних ключей или таблиц соединения. В JPA имеется набор метаданных для управления отображением связей. Даже наследование может быть отображено. Оно широко применяется разработчиками для повторного использования кода, однако эта концепция изначально неизвестна в сфере реляционных баз данных (поскольку им приходится эмулировать наследование с использованием внешних ключей и ограничений). Даже если и придется прибегнуть к некоторым трюкам при отображении наследования, JPA поддерживает его и предлагает вам три разные стратегии на выбор.