Сутність (Entity) у Spring Data JPA

Рис. 11.1. Клас User з JPA-анотаціями. Він стане таблицею users у базі даних.

1) Що таке “сутність” (Entity) простими словами

Entity — це Java-клас, який описує один тип даних у нашій системі так, як він буде зберігатися в базі даних.

Якщо є сутність User — у БД з’являється таблиця users.
Кожен об’єкт User — це один рядок у таблиці.
Поля класу — це колонки таблиці.

Чому так роблять: ми працюємо в коді з Java-об’єктами, а не з SQL-рядками. JPA “перекладає” наші дії (save/find/delete) у SQL запити.

2) Що ми зараз створили в проєкті

Ми створили клас User у пакеті com.example.demo.model.

Це “модель даних” для користувача, яка містить:

id — унікальний ідентифікатор (первинний ключ);
name — ім’я користувача;
email — email користувача.

Далі ми зробимо Repository, Service, Controller — і зможемо керувати користувачами через API.

3) Навіщо сутності взагалі потрібні (що вони “дають”)

Автоматичне створення таблиць (якщо увімкнено ddl-auto).
Збереження об’єкта в БД через repository.save(user).
Пошук без SQL: findAll(), findById(), findByEmail().
Оновлення: змінюєш поле в об’єкті → save → дані в БД оновились.
Видалення: deleteById(id).

По факту: сутність — це “контракт” між кодом і базою даних. Якщо сутність описана правильно, більшість CRUD логіки робиться майже автоматично.

4) Розбір анотацій: що означає кожна

@EntityОзначає: цей клас — сутність для JPA.

Без @Entity Spring Data JPA не буде сприймати цей клас як таблицю/рядки. Це як “позначка”, що клас треба зберігати в БД.

@Table(name="users")Явно задає назву таблиці.

Якщо @Table не вказувати, JPA спробує сама назвати таблицю (наприклад User → user). Але слово user часто конфліктне (зарезервоване) в деяких БД, тому краще задати users.

@IdПозначає поле як первинний ключ (Primary Key).

Первинний ключ — це колонка, яка унікально ідентифікує рядок. Двоє користувачів не можуть мати один і той самий id.

@GeneratedValueКаже: id генерує база або JPA автоматично.

Тобто ми не пишемо вручну id = 1, id = 2... При вставці нового рядка база сама “видає” наступний номер.

GenerationType.IDENTITYСтратегія генерації “auto increment”.

Це типовий варіант для MySQL/H2: у таблиці є автоінкремент і база сама збільшує значення. Альтернативи існують (SEQUENCE, TABLE), але для навчальної практичної IDENTITY — найпростіше.

5) Розбір полів: що вони означають в БД

Long idУ БД буде колонка типу BIGINT (або аналог). Це “номер користувача”.

String nameУ БД буде колонка типу VARCHAR. Ім’я користувача.

String emailУ БД теж VARCHAR. Email користувача.

Що важливо пояснити студентам: типи даних Java і типи БД — різні, але JPA вміє їх “мапити”. Наприклад String → VARCHAR, Long → BIGINT.

6) Навіщо потрібен порожній конструктор public User() {}

JPA (Hibernate) часто створює об’єкт сутності “сам” через reflection. Для цього потрібен конструктор без параметрів.

Якщо його не буде — можуть виникнути помилки при завантаженні сутності з БД. Тому правило: у сутності майже завжди має бути порожній конструктор.

7) Яка таблиця з’явиться в БД (і як вона виглядатиме)

Після запуску застосунку (якщо налаштовано створення таблиць) буде приблизно так:

CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255), email VARCHAR(255) );

Це приклад. Реальні типи та довжини можуть відрізнятися залежно від БД і налаштувань. Але логіка завжди одна: клас → таблиця, об’єкт → рядок.

8) Типові помилки (щоб студенти не “залипли” на дрібницях)

Забули додати залежність Spring Data JPA → @Entity “не працює”.
Неправильний package name → Spring не знаходить компоненти (але entity зазвичай ок).
Немає порожнього конструктора → Hibernate може падати.
Немає @Id → JPA не розуміє, як ідентифікувати рядок.

Підсумок: сутність — це фундамент. Далі ми створимо Repository, який дозволить нам працювати з таблицею users “одним рядком коду”.