Comments 17
Эта статься для новичков в чем?
В итогах вы немного лукавите — «Мы создали приложение». Правильно было бы — мы разобрались как использовать kotlin c jpa.
Вот константый hashcode — это интересный ньюанс. В целом спасибо за статью!
Вот константый hashcode — это интересный ньюанс. В целом спасибо за статью!
Очень похоже, что это просто перевод этой статьи
kotlinexpertise.com/hibernate-with-kotlin-spring-boot
kotlinexpertise.com/hibernate-with-kotlin-spring-boot
У статей на эту тематику всегда будет много общего. Так как, на данный момент, иначе полноценно завести это на Kotlin просто не получится. Да и про тот же hashCode с константой, относящийся и тематике Java, тоже есть статьи, это не является секретом.
А зачем вы вообще пытаетесь слепить вместе фреймворки ориентированные на Java Enterprise и Kotlin? Из статьи я увидел только несколько упоминаний про синтаксический сахар. Но вся прелесть Kotlin в многопоточности, его замечательных корутинах, которая в таких связках рубится. Если это новый проект, то почему бы его целиком не сделать на Kotlin. В качестве сервера взять Ktor, а для работы с БД Exposed. Что бы всё было стопроцентно совместимо и поддерживало все фичи Kotlin.
Потому что могут быть решения, что на Java используется «такой-то» технический стек, а при замене ЯП никто не готов и стек полностью заменить. Для этого нужно время, апробирование на внутренних тестовых сервисах. Нельзя так просто вылить в прод новый сервис когда у остальной команды нет тех. экспертизы для его поддержки.
И да, Spring Framework, Hibernate и прочие из мира Java EE писались именно под особенности языка Java SE. Так как у Kotlin другая философия то приходится применять плагины, не меняя в остальном работу с Kotlin.
Фреймворки-то не изменить уже, работаем с тем что есть.
Время пройдёт, возможно будут заменены и фреймворки, уже написанные под Kotlin.
И да, Spring Framework, Hibernate и прочие из мира Java EE писались именно под особенности языка Java SE. Так как у Kotlin другая философия то приходится применять плагины, не меняя в остальном работу с Kotlin.
Фреймворки-то не изменить уже, работаем с тем что есть.
Время пройдёт, возможно будут заменены и фреймворки, уже написанные под Kotlin.
Поэтому я и пишу, что это как минимум необдуманное решение. Т.е. заменять язык имеет смысл, если планируется использовать все те возможности, которые он предоставляет. И соответственно с новым языком должна приходить новая философия и архитектура. Но если же на новом языке ведётся разработка в джава-стиле, то появляются только новые проблемы и никакой выгоды. А отсюда и возникает вопрос: а зачем это вообще нужно?
Джава сейчас развивается ничуть не медленнее, чем Котлин. Все удачные решения одного языка наверняка найдут отражение и в другом. Так что не проще ли было просто апдейтится до актуальной версии Джавы?
Джава сейчас развивается ничуть не медленнее, чем Котлин. Все удачные решения одного языка наверняка найдут отражение и в другом. Так что не проще ли было просто апдейтится до актуальной версии Джавы?
А использование LocalDateTime для created и modified это правильный выбор? Там же хранится не момент времени, а дата без привязки к таймзоне. Мне кажется Instant тут лучше подходит.
LocalDateTime использован для простоты, целью было продемонстрировать применения lateinit var. Да, в самом LocalDateTime не хранится момент времени, но для его инициализации в качестве поля аудита используется дефолтная тайм зона а на сам timestamp конвертируется значение как есть. Поэтому для примера в статье тайм зоны я не рассматривал так как в этом не было необходимости
Замечательная статья) Узнал много интересных вещей. Пользуюсь тем же стеком. Было бы интересно узнать как пишите тесты. А ещё мне очень интересно узнать, как решаете проблему с десериализацией POST/PUT запросов. jackson требует (даже при десериализации через конструктор), чтобы все поля были nullable даже те, что определённо такими быть не должны, и я навесил на них соответствующую валидацию с помощью hibernate-validator. Сам решаю классом-обёрткой и оператором !!, но есть ощущение, что можно и лучше.
Спасибо за отзыв! Рассмотрю возможность включение тестов в следующих статьях. По поводу десериализации: если я правильно понял Ваш вопрос, то мы используем data классы в качестве dto и jackson-module-kotlin — это как раз модуль который позволяет объявить primary constructor у data класса с не nullable полями
Отличная статья!
Отдельная благодарность за детальное описание причины недопустимости использования Data-классов в качестве сущностей Hibernate!
Отдельная благодарность за детальное описание причины недопустимости использования Data-классов в качестве сущностей Hibernate!
Sign up to leave a comment.
Spring Boot, Hibernate и Kotlin для новичков шаг за шагом