Spring Boot, Hibernate и Kotlin для новичков шаг за шагом

Всем привет, меня зовут Олег, я техлид в ДомКлике. В нашей команде ядром стека является Kotlin и Spring Boot. Хочу поделиться с вами своим опытом по взаимодействию и особенностях работы с PostgreSQL и Hibernate в связке со Spring Boot и Kotlin. Также на примере микросервиса, покажу преимущества Kotlin и его отличия от аналогичного приложения на Java. Расскажу о не совсем очевидных сложностях, с которыми могут столкнуться новички при использовании этого стека с Hibernate. Статья будет полезна разработчикам, желающим перейти на Kotlin и знакомых со Spring Boot, Hibernate Java.

Плагины

Для приложения на Kotlin в качестве сборщика проекта возьмём Gradle Kotlin DSL. Список подключенных плагинов будет стандартным для Spring Boot, а для Kotlin с Hibernate у нас появится несколько новых:

plugins {     id("org.springframework.boot") version "2.2.7.RELEASE"     id("io.spring.dependency-management") version "1.0.9.RELEASE"     kotlin("jvm") version "1.3.72"     kotlin("plugin.spring") version "1.3.72"     kotlin("plugin.jpa") version "1.3.72" } 

Рассмотрим три последних.

kotlin(«jvm») — базовый плагин Kotlin для работы на JVM. Без которого не заведется ни одно приложение на Java-стеке.

kotlin(«plugin.spring») — поскольку классы в Kotlin по умолчанию финальны, то этот плагин автоматически сделает классы, помеченные аннотациями @Component, @Async, @Transactional, @Cacheable и @SpringBootTest открытыми к наследованию, а в тематике, относящейся этой статье, это позволит классам, написанным на Kotlin быть проксированными в Spring через CGLib прокси.

Важно отметить, что сущности, помеченные аннотациями @Entity, @MappedSuperclass и @Embaddable, не станут open после подключения плагина. Более того, get accessor’ы тоже будут финальными, и тогда мы потеряем возможность работать с entity reference. Чтобы этого избежать и сделать Entity и его поля open, добавим в build.gradle.kts:

allOpen {    annotation("javax.persistence.Entity")    annotation("javax.persistence.MappedSuperclass")    annotation("javax.persistence.Embeddable") }

kotlin(«plugin.jpa») — Если предыдущие два плагина применяются к любому приложению на Kotlin + Spring Boot, то следующий, уже относится напрямую к Hibernate. А он, как известно, для инициализации Entity использует рефлексию и инициализирует класс с конструктором без аргументов. Но так как мы пишем на Kotlin, такового конструктора может и не найтись. Если мы определили свой собственный первичный конструктор (primary constructor), то при загрузке Entity у нас выкинет исключение:

org.hibernate.InstantiationException: No default constructor for entity 

Зависимости

Набор зависимостей у нас тоже будет не совсем идентичный набору на Java:

dependencies {   implementation("org.springframework.boot:spring-boot-starter-web")   implementation("org.springframework.boot:spring-boot-starter-data-jpa")   implementation("com.fasterxml.jackson.module:jackson-module-kotlin")   implementation("org.jetbrains.kotlin:kotlin-reflect")   implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")   implementation("org.liquibase:liquibase-core")    runtimeOnly("org.postgresql:postgresql")    testImplementation("org.springframework.boot:spring-boot-starter-test")   testImplementation("org.testcontainers:testcontainers:$testContainersVer")   testImplementation("org.testcontainers:postgresql:$testContainersVer") }

Добавим еще пару зависимостей в дополнение к стандартному веб-стартеру Spring Boot и к основному интересующему нас стартеру org.springframework.boot:spring-boot-starter-data-jpa, который в качестве реализации JPA по умолчанию тянет Hibernate:

org.jetbrains.kotlin:kotlin-reflect — нужен для рефлексии на Kotlin, которая уже поддерживается в Spring Boot и широко используется для инициализации классов.

org.jetbrains.kotlin:kotlin-stdlib-jdk8 — добавляет возможность работать с коллекциями Java, поддержку стримов и многое другое.

На этом различия в конфигурировании проекта на Kotlin по сравнению с Java у нас заканчиваются, перейдем к самому проекту, его структуре таблиц и сущностей.

Таблицы и сущности

Наше приложение будет состоять из двух таблиц department и employee, которые связаны отношением «один ко многим».

Структура таблиц:

В качестве базы будем использовать СУБД PostgreSQL. Структуру таблиц создадим с помощью liquibase, а в качестве тестовых зависимостей будем использовать стандартный стартер:

org.springframework.boot:spring-boot-starter-test — тестировать будем в Docker с помощью testcontainers.

Сущности

Как и в любом приложении с более чем одной сущностью, создадим общего предка для всех entity.

BaseEntity:

@MappedSuperclass abstract class BaseEntity<T> {     @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    var id: T? = null     override fun equals(other: Any?): Boolean {        other ?: return false         if (this === other) return true         if (javaClass != ProxyUtils.getUserClass(other)) return false         other as BaseEntity<*>         return this.id != null && this.id == other.id    }     override fun hashCode() = 25     override fun toString(): String {        return "${this.javaClass.simpleName}(id=$id)"    } }

DepartmentEntity:

@Entity @Table(name = "department") class DepartmentEntity(         val name: String,         @OneToMany(                mappedBy = "department",                fetch = FetchType.LAZY,                orphanRemoval = true,                cascade = [CascadeType.ALL]        )        val employees: MutableList<EmployeeEntity> = mutableListOf() ) : BaseAuditEntity<Long>() {     fun addEmployee(block: DepartmentEntity.() -> EmployeeEntity) {        employees.add(block())    }     fun setEmployees(block: DepartmentEntity.() -> MutableSet<EmployeeEntity>) {        employees.clear()        employees.addAll(block())    } }

EmployeeEntity:

@Entity @Table(name = "employee") class EmployeeEntity(         val firstName: String,         var lastName: String? = null,         @ManyToOne        @JoinColumn(name = "department_id")        val department: DepartmentEntity ) : BaseAuditEntity<Long>()

Мы не используем Data-классы. Это кажется явным преимуществом Kotlin перед Java (до 14 версии), и этому есть объяснение.

Почему не использовать?

Data-классы, помимо того, что они финальны сами по себе, имеют по всем полям определенные equals, hashCode и toString. А это недопустимо в связке с Hibernate.

Почему? А также зачем hashCode всегда равен константе — ответ в документации самого Hibernate. Конкретно нас интересует вот этот раздел:

Although using a natural-id is best for equals and hashCode, sometimes you only have the entity identifier that provides a unique constraint.

It’s possible to use the entity identifier for equality check, but it needs a workaround:

• you need to provide a constant value for hashCode so that the hash code value does not change before and after the entity is flushed.
• you need to compare the entity identifier equality only for non-transient entities.

То есть сравнивать нужно либо по natural id, либо, как в нашем примере, по primary key id. Это позволит избежать множества проблем при сравнении сущности и убережет от ее потери при использовании сущности в качестве элемента в Set.

Наличие же toString, определенного по всем полям, и вовсе убивает всю ленивость, например, при журналировании сущности, так как будут проинициализированы все поля для вывода в строку.

Учитывая особенности Hibernate, эта функциональность Kotlin нам не подойдет.

Конструктор класса

Kotlin позволяет задавать переменным значения через конструктор, чем грех не воспользоваться. Рассмотрим еще раз DepartmentEntity:

class DepartmentEntity(         val name: String,         @OneToMany(                mappedBy = "department",                fetch = FetchType.LAZY,                orphanRemoval = true,                cascade = [CascadeType.ALL]        )        val employees: MutableList<EmployeeEntity> = mutableListOf() ) : BaseAuditEntity<Long>() {

Также мы можем проинициализировать через конструктор название подразделения, например:

departmentRepository.save(DepartmentEntity(name = "Department One"))

Через конструктор можно инициализировать, в том числе, и список сотрудников employees. Коллекции, разумеется, объявим изменяемыми.

Используйте var/val в зависимости от необходимости изменения поля

Название организации мы пометили как val:

class DepartmentEntity(         val name: String,

и оно не может быть null.

Выбор var/val является удобной опцией и зависит от бизнес-логики. Выбирать между var и val надо исходя из требования: должно ли поле сущности быть изменяемым.

Допустимость null в полях только в соответствии с БД

Насчет допустимости значений null в полях всё не так просто. Ранее мы погрузились немного в глубины Hibernate: говоря о plugin.jpa, я упомянул про использование конструктора без аргументов при инициализации сущности.

При инициализации полей тоже используется рефлексия. И если в базе в соответствующей колонке хранилось значение null, то класс спокойно инициализируется с этим полем со значением null. При обращении к нему мы рискуем получить NPE, хотя поле и помечено как not nullable. Чтобы этого не случилось, надо следить за синхронностью структуры таблиц и классов.

Если посмотреть на описанное в последних двух разделах более комплексно, то эти правила применимы не только к примитивам, но и к связке сущностей.

Например, EmployeeEntity всегда привязан к DepartmentEntity:

class EmployeeEntity(         val firstName: String,         var lastName: String? = null,         @ManyToOne        @JoinColumn(name = "department_id")        val department: DepartmentEntity ) : BaseAuditEntity<Long>()

Department является не null и его нельзя изменить, что может избавить от разного рода ошибок, в особенности, если бизнес-логика требует неизменяемости.

Репозитории

При использовании Kotlin, у репозиториев из коробки появилась проверка на допустимость null. Так, если мы уверены, что при поиске department по имени результат будет уникальный и единственный, то можно возвращаемый тип указать как non nullable:

interface DepartmentRepository : JpaRepository<DepartmentEntity, Long> {     fun findOneByName(name: String) : DepartmentEntity }

Здесь DepartmentEntity указан единственным и не может быть null. Если же по какой-то причине мы не нашли искомый department, то поймаем уже не NPE, а нечто другое:

org.springframework.dao.EmptyResultDataAccessException: Result must not be null! 

Такая обработка достигается с помощью добавления специализированной поддержки Kotlin в MethodInvocationValidator и ReflectionUtils в spring data commons.

lateinit var

Ещё одной фичей Kotlin, которую хотелось бы рассмотреть, является lateinit var.

Добавим новый класс-предок: BaseAuditEntity.

@MappedSuperclass @EntityListeners(AuditingEntityListener::class) abstract class BaseAuditEntity<T> : BaseEntity<T>() {     @CreatedDate    @Column(updatable = false, nullable = false)    lateinit var created: LocalDateTime     @LastModifiedDate    @Column(nullable = false)    lateinit var modified: LocalDateTime }

Рассмотрим применение lateinit var на примере полей аудита (created, modified).

lateinit var — это not null поле с отложенной инициализацией. Обращение к полю до его инициализации генерирует ошибку:

kotlin.UninitializedPropertyAccessException: lateinit property has not been initialized 

Как правило, мы обращаемся к полям created и modified уже после того, как сущность была сохранена в БД. В нашем случае, данные в этих поляхпроставляются на этапе сохранения и они not null, то lateinit var нам более чем подходит.

Итоги

Мы создали приложение, в котором учтены многие преимущества Kotlin, и рассмотрели важные отличия от Java, избежав многих скрытых сюрпризов. Буду рад, если эта статья окажется полезна не только новичкам. Позднее мы продолжим тему общения микросервиса с БД.

Ссылка на приложение.