Читаем Изучаем 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 поддерживает его и предлагает вам три разные стратегии на выбор.