Одна операция, четыре уровня

1. Четыре слова, одна причина путаницы

Причина путаницы довольно честная: все четыре уровня persistence решают одну и ту же общую задачу — помогают Java-приложению работать с данными в реляционной БД. Поэтому со стороны может казаться, что различия между ними косметические. Но на практике всё упирается как раз в уровень ответственности.

JDBC — это низкий уровень. Там разработчик сам пишет SQL, сам передаёт параметры, сам читает результат. JPA — это стандарт API для работы с persistence-моделью. Hibernate — это ORM-реализация, которая этот стандарт обычно исполняет. Spring Data JPA — это ещё более высокий слой, который даёт форму репозиториев поверх JPA.

Если проговорить это сухо, получится почти словарь. Поэтому полезно держать в голове одну практическую мысль: все четыре уровня отвечают на вопрос «как получить данные из БД в Java», но делают это с разной долей ручной работы и с разной степенью абстракции ⚙️

2. Наш сценарий: загрузить товар по id

В mini-shop это обычная операция. Нужно найти товар, чтобы показать карточку, отдать его в сервис, проверить цену или подготовить какую-то бизнес-логику. Важный момент: сам смысл операции не меняется от уровня к уровню. Меняется только то, на каком языке вы эту операцию выражаете.

На JDBC-уровне вы говорите языком SQL, соединений и ResultSet. На JPA-уровне — языком сущностей и EntityManager. На Hibernate-уровне — языком конкретного ORM-движка, который знает, как реализовать JPA-контракт. На уровне Spring Data JPA — языком контракта репозитория.

Именно это делает сравнение полезным. Мы смотрим не на четыре разных сценария, а на одну и ту же задачу. А значит, легче увидеть: главное различие здесь — в уровне удобства и ответственности, а не в том, что это «совсем разные технологии».

3. JDBC: вручную общаемся с БД через SQL️

На JDBC-уровне всё максимально честно. Вы открываете соединение, пишете SQL, подставляете параметры, выполняете запрос и читаете результат. Никакой иллюзии, что база данных исчезла. Это очень «ручной» режим, но именно он отлично показывает фундамент.

Условная операция «найти товар по id» выглядит так:

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;

Product loadProductById(Connection connection, long id) throws Exception {
    // Готовим SQL с плейсхолдером, чтобы безопасно подставить id 
    PreparedStatement ps = connection.prepareStatement(
            "select id, sku, name, price from product where id = ?"
    );

    // Передаём параметр в запрос: первый плейсхолдер (?) получит значение id
    ps.setLong(1, id);

    // Выполняем запрос и получаем "курсор" по строкам результата
    ResultSet rs = ps.executeQuery();

    // Переходим на первую строку; если строк нет — товар не найден
    if (!rs.next()) {
        return null;
    }

    // Вручную собираем доменный объект из колонок ResultSet
    Product product = new Product();
    product.setId(rs.getLong("id"));              // читаем колонку id
    product.setSku(rs.getString("sku"));          // читаем sku
    product.setName(rs.getString("name"));        // читаем name
    product.setPrice(rs.getBigDecimal("price"));  // читаем price (например, BigDecimal для денег)
    return product; // возвращаем полностью собранный объект
}

Здесь хорошо видно цену полного контроля. SQL вы написали сами. Параметр подставили сами. Из ResultSet объект тоже собрали сами. Это и есть сила JDBC: ничего не скрыто. И это же его цена: много рутины, которую приходится повторять снова и снова 🔧

В реальных проектах JDBC никуда не девается. Даже если вы работаете на более высоком уровне, где-то внизу приложение всё равно общается с БД именно через JDBC. Поэтому считать JDBC «ненужным старьём» — плохая идея. Это фундаментальный этаж стека, а не музейный артефакт.

4. JPA: поднимаемся на уровень EntityManager

JPA меняет язык общения. Вместо того чтобы руками собирать Product из ResultSet, вы начинаете мыслить в терминах сущностей и persistence API. Центральный объект этого уровня — EntityManager. Он сам по себе не является хранилищем, но даёт стандартный способ работать с persistence-моделью.

Тот же сценарий на JPA-уровне выглядит гораздо компактнее:

import jakarta.persistence.EntityManager;

Product loadProductById(EntityManager entityManager, long id) {
    // Просим persistence context/ORM найти сущность по первичному ключу (обычно это PK таблицы)
    return entityManager.find(Product.class, id);
}

Это не магия, а просто другой уровень абстракции. Вы говорите: «дай мне сущность Product с таким id», а не «сделай SELECT, прочитай колонки и руками создай объект». JPA стандартизирует именно такой способ мышления.

Очень важно при этом не спутать JPA с конкретной библиотекой. JPA — это не «движок», а стандартный контракт. Он определяет, какими понятиями вы оперируете: сущность, EntityManager, операции чтения и записи, persistence context и так далее. Но кто-то должен этот контракт реально исполнять. И вот здесь на сцену выходит Hibernate.

5. Hibernate: движок, который реально выполняет ORM-механику 🛠️

Когда вы пишете entityManager.find(Product.class, id), JPA не «ходит в базу» сама. JPA — это API и правила. Реальную работу обычно делает Hibernate как JPA-провайдер. Именно он знает, как смаппить сущность на таблицу, как сформировать SQL, как загрузить данные, как отслеживать изменения объектов и как потом отправить UPDATE в БД.

Иногда Hibernate можно увидеть и напрямую:

import org.hibernate.Session;

Product loadProductById(Session session, long id) {
    // Hibernate Session — "родной" API Hibernate; по смыслу очень похоже на EntityManager.find(...)
    return session.find(Product.class, id);
}

Но даже если вы никогда не пишете Session вручную, Hibernate всё равно работает под капотом. Это полезно понимать по одной причине: когда приложение генерирует SQL, отслеживает dirty checking, держит persistence context и реагирует на mapping-конфигурацию, это уже область ORM-реализации, а не просто «какая-то аннотация JPA».

Хорошая спокойная формулировка звучит так: JPA описывает правила игры, а Hibernate выходит на поле и реально играет матч. Если держать это в голове, сразу уменьшается путаница вокруг слов «стандарт» и «реализация».

6. Spring Data JPA: репозиторий как контракт

Следующий шаг вверх — это Spring Data JPA. Здесь вы обычно уже не работаете напрямую с EntityManager в каждом сервисе. Вместо этого вы описываете контракт репозитория, а Spring создаёт реализацию поверх JPA за вас.

Тот же сценарий чтения товара по id может выглядеть так:

import org.springframework.data.jpa.repository.JpaRepository;

interface ProductRepository extends JpaRepository<Product, Long> {
    // Пустой интерфейс — это нормально:
    // Spring Data JPA сам добавит базовые CRUD-методы (findById, save, delete и т.д.)
    // на основе JpaRepository<Product, Long>
}

А сервис использует этот репозиторий так:

class CatalogService {
    private final ProductRepository productRepository; // зависимость на репозиторий (контракт доступа к данным)

    CatalogService(ProductRepository productRepository) {
        // внедрение зависимости (обычно это делает Spring через DI)
        this.productRepository = productRepository;
    }

    Product loadProduct(long id) {
        // findById возвращает Optional<Product>, чтобы явно показать "может не найтись"
        // orElseThrow() — поднимем исключение, если товара нет (политика обработки отсутствия данных)
        return productRepository.findById(id).orElseThrow();
    }
}

Теперь язык стал ещё выше. Сервис не знает ни про SQL, ни про EntityManager. Он знает только, что у него есть контракт репозитория. Но это не значит, что нижние уровни исчезли. Под этим контрактом всё равно живут JPA, Hibernate и JDBC. Просто часть рутины и стандартных реализаций теперь берёт на себя Spring Data JPA.

Spring Data JPA — это не «другая база данных» и не «замена Hibernate». Это верхний слой удобства над тем стеком, который всё равно остаётся под вами.

7. Лестница абстракций в одной таблице 🪜

Теперь можно собрать всё в компактную карту. Её полезно держать в голове всякий раз, когда вы видите в коде очередной repository, а в логах — SQL и Hibernate-сообщения.

Эта таблица полезна не как шпаргалка для собеседования, а как инструмент ориентации. Когда вы понимаете, на каком уровне сейчас стоите, отладка и обучение становятся спокойнее. Вы перестаёте ждать от repository того, что относится к SQL, и перестаёте ругать Hibernate за то, что на самом деле зависит от JPA-модели или от структуры запроса.

8. Верхний слой не отменяет нижний

Вот главная мысль всей лекции. Верхний уровень абстракции не уничтожает нижний. Он просто даёт более удобную форму работы. Если вы используете JpaRepository, это не значит, что JDBC исчез. Если вы пишете через EntityManager, это не значит, что SQL отменён. Если вы знаете JPA, это не значит, что Hibernate стал не нужен.

Именно поэтому в реальной жизни в одном и том же приложении вы одновременно встречаете все эти слова. Сервис работает с репозиторием. Репозиторий опирается на JPA. JPA реализуется Hibernate. Hibernate использует JDBC, чтобы сходить в PostgreSQL. Это не хаос. Это стек.

С этого момента технология обычно перестаёт казаться мистикой 😌 А это очень ценно для всего курса. Потому что дальше мы будем говорить про repositories, queries, transactions, persistence context и generated SQL — и у вас уже будет карта, куда всё это встаёт.

9. Что это меняет в вашем мышлении

Во-первых, вы больше не обязаны воспринимать repository как чёрный ящик. Теперь видно, что это просто верхний контракт слоя данных, а не самостоятельная вселенная. Во-вторых, становится понятнее, почему курс по Spring Data JPA вообще не начинается с механического save() и не заканчивается findById().

Этот курс стоит после Spring Core и Spring Boot именно потому, что контейнер, связывание компонентов и базовая инфраструктура Spring уже должны быть вам знакомы. Здесь фокус другой: контроль над слоем данных. А контроль невозможен, если весь стек в голове склеен в один термин 🧠

И ещё одно важное следствие. Раз нижние этажи никуда не исчезают, значит без SQL-мышления дальше всё равно не обойтись. Именно поэтому следующий фундаментальный шаг выглядит логично: разобраться, как объектная модель вообще стоит на реляционной модели и почему ORM не отменяет таблицы, JOIN и транзакции.

10. Типичные ошибки 🚫

Ошибка №1: говорить “Hibernate” там, где вы имеете в виду вообще весь стек.
Это не смертельно в разговоре, но очень мешает инженерному мышлению. Лучше различать: JPA — стандарт, Hibernate — реализация, Spring Data JPA — слой репозиториев поверх JPA.

Ошибка №2: считать Spring Data JPA самостоятельным хранилищем.
Spring Data JPA не хранит данные «сам по себе». Он даёт удобный способ писать репозитории поверх JPA-провайдера и реальной БД.

Ошибка №3: думать, что если вы не пишете SQL, значит SQL нет.
SQL просто уехал уровнем ниже. Он всё равно будет выполняться, а значит его форму и последствия всё равно полезно понимать.

Ошибка №4: пытаться учить стек как список несвязанных определений.
Гораздо полезнее брать одну операцию и смотреть, как она проходит по уровням. Тогда термины перестают быть мёртвыми.