В каких случаях оправдано использование чистого JDBC вместо ORM (например, Hibernate) для CRUD-операций?

Использование чистого JDBC вместо ORM оправдано в узких сценариях, где его преимущества перевешивают недостатки в виде boilerplate-кода.

Когда JDBC предпочтительнее:

1. Критическая производительность: Для высоконагруженных операций, где накладные расходы ORM (генерация SQL, отслеживание состояния объектов, кэширование) неприемлемы. Прямой контроль над SQL и PreparedStatement позволяет делать тонкую оптимизацию.
2. Сложные запросы и отчеты: Когда требуются многотабличные JOIN, оконные функции или специфические оптимизации СУБД, которые сложно или неэффективно выразить через ORM.
3. Легковесные приложения: В микросервисах или утилитах, где подключение полноценного ORM избыточно.
4. Работа с legacy-схемой: Со сложной, не нормализованной или плохо документированной схемой БД, которую сложно отобразить на объектную модель.

Пример простого CRUD на JDBC:

public User findById(long id) throws SQLException {
    String sql = "SELECT id, name FROM users WHERE id = ?";
    try (Connection conn = dataSource.getConnection();
         PreparedStatement ps = conn.prepareStatement(sql)) {
        ps.setLong(1, id);
        try (ResultSet rs = ps.executeQuery()) {
            if (rs.next()) {
                return new User(rs.getLong("id"), rs.getString("name"));
            }
        }
    }
    return null;
}

Вывод: Для типичных CRUD-операций в enterprise-приложениях ORM (JPA/Hibernate) является стандартом, так как повышает скорость разработки, безопасность (защита от SQL-инъекций) и поддерживаемость. JDBC — это инструмент для специфических, оптимизированных сценариев.