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, избежав многих скрытых сюрпризов. Буду рад, если эта статья окажется полезна не только новичкам. Позднее мы продолжим тему общения микросервиса с БД.

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

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