Gdy opisałem data classes to praktycznie od razu pojawiło się pytanie, a co z ich użyciem jako encje? Spróbujmy zatem. Wygenerowałem projekt spring boot, bo mam już wtedy skonfigurowane JPA w sposób podobny do tego, jaki występuje w wielu projektach.

Encja – to proste

Kotlin wspiera adnotacje, a zatem stworzenie encji jest bardzo proste. Wystarczy zdefiniować dc z odpowiednią adnotacją:

Listing 1. Definicja encji w kotlinie

@Entity
data class Phone(@Id var id: Long)

I to już wystarczy do szczęścia. Klasa ma wszystko, co potrzeba adnotację @Entity oraz jedno pole, które jest identyfikatorem oznaczone @Id. Lubię jak szybko i bez problemowo można zintegrować dwie rzeczy.

Zależności pomiędzy encjami

Sama pojedyncza encja bez zależności do innych elementów w modelu jest trochę jak onanista. Niby wszystko ok, ale to nie to samo. Trochę obawiałem się tego, jak będzie wyglądać encja po dodaniu zależności, ale okazało się, że nie jest tak źle:

Listing 2. Encja z zależnością 1-\*

@Entity
data class Phone(@Id var id: Long, var number: String,
                 @ManyToOne
                 @JoinColumn(name = "owner_id")
                 var owner: User)

Listing 3. Encja z zależnością \*-1

data class User(@Id var id: Long, var firstName: String, var lastName: String,
                @OneToMany(mappedBy = "owner")
                var phones: List<Phone>)

Zatem nie jest tak źle. To o czym trzeba pamiętać to, że adnotacje są doszywane do pól, a nie metod. Zatem jeżeli z jakiegoś powodu chcemy mieć adnotacje na metodach to odpuśćmy sobie dc, bo tracimy ich zalety.

Podsumowanie

Nie wykonałem pełnej pracy. Nie sprawdziłem, w jaki sposób zadziałają pewne specyficzne rodzaje wiązań np. @Embedded, ale prawdę powiedziawszy nie wiele mnie to 😉 Niektórych rzeczy nie trzeba sprawdzać, bo na przykład dc nie mogą dziedziczyć zatem odpada nam cała zabawa z dziedziczeniem w JPA. I jest to dość poważne ograniczenie, które dyskwalifikuje Kotlina w pewnych specyficznych zastosowaniach.