Перешли на рекорды, по сути те же POJO, но красивее и быстрее. Мапстракт отлично справляется, забыл уже когда писал хоть какойто мапинг. Для сериализации десериализации юзаем уже моделМаппер Jackson, удобно, легко мапит и снейк_кейс и камелКейс. Jakcson с версии 2.15 с рекордами работает.
спасибо большое, было познавательно, от себя добавлю что mybatis + ломбок достаточно хорошо решает данные проблемы так как с используем подход pojo и pojo filter extend pojo
У нас Kotlin, мы трансформации (mapping) производим в контроллерах либо extension функции, либо отдельные классы-мапперы, если нужно закинуть зависимости. Смотрю на MapStruct, выглядит как-то тяжеловеснее или примерно так же, как инстанциирование классов в Kotlin. Вывод от себя, в Kotlin MapStruct - это пятое колесо
А какая разница где? Все равно писать миллион присваиваний где то надо. Мапстракт справляется именно с этим. А позвать его можно и из экстеншен функции... Это ради бога.
@@AlekseyStukalov так о том-то и речь, что он, конечно, справляется... но 1. Кода в котлин я напишу +- столько же по количеству, сколько в мапстракт 2. В мапстракт вот эта история с описанием вычисляемых полей на EL ещё и несёт риск того, что при будущем рефакторинге IDE может либо просто на этот EL положить, либо криво его зарефачить. А если не дай бог препроцессору IDE вообще плевать на этот EL, то ошибки мы собирать уже будем в рантайм
@user-mj6tf8dc1d 1. Да ладно? А можно посмотреть маппинг графа, например глубиной 3, по 5 аттрибутов на каждой сущности? Мапстракт как раз весь этот код аккуратненько генерит. 2. Так EL то вообще не обязательно использовать. Пишите вычисляемые поля сразу в себя в DTO или на уровне сущности транзиентными полями и все помапится прекрасно. Это слабый аргумент ИМХО.
ты о чем? из репозитория можно доставать данные не только сущностей но и любой дто. Главное чтобы типы и названия полей совпадали. другое дело что это не используют ибо нужно будет слишком много этих методов делать для каждой дто. Проще достать основную сущность и замапить ее в нужное.
Мапперы вообще унылая возня, на порядок проще и удобнее и понятнее и быстрее обычным присваиванием делать. Я понимаю если требуется по 10 сайтов клепать в день, тогда можно эти инструменты использовать, но когда у вас ентерпрайс что вы выиграете этой возней
как раз в энтерпрайзах это и используется. Когда их за сотни маппингов. Тип и имя совпали и ничего делать не надо. И когда в объекте пару десятков полей, при ручном маппинге вообще каша читаемости будет
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Перешли на рекорды, по сути те же POJO, но красивее и быстрее. Мапстракт отлично справляется, забыл уже когда писал хоть какойто мапинг. Для сериализации десериализации юзаем уже моделМаппер Jackson, удобно, легко мапит и снейк_кейс и камелКейс. Jakcson с версии 2.15 с рекордами работает.
Кайфанул прям, Спасибо огромное :)
спасибо большое за видео, много знал, однако услышал и много интересного и полезного!
спасибо большое, было познавательно, от себя добавлю что mybatis + ломбок достаточно хорошо решает данные проблемы так как с используем подход pojo и pojo filter extend pojo
Сочувствую Вам ребята((
Не думал, что в Java так шатко работать с данными
В этом вся суть
Отличный кодлад
37:53 Проекции, тут получается, что мы можем только одно вычисляемое поле добавить таким способом, так ведь?
Спасибо
Итого jpa создает больше проблем, чем решает
can not agree more! we use raw jdbc for at least 10 years now, we do not miss any jpa/hibernate at all
Кто-то еще произносит DTO как "ди-ти-о"? У нас в офисе все всегда произносили просто как "дто")
Да, особенно когда с иностранцами общаешься, иначе беда 🙂
У меня такая деформация. И, например, "Джи Даблью Ти" вместо ГВТ. Это зависит от того какой язык рабочий англ или рус.
У нас Kotlin, мы трансформации (mapping) производим в контроллерах либо extension функции, либо отдельные классы-мапперы, если нужно закинуть зависимости. Смотрю на MapStruct, выглядит как-то тяжеловеснее или примерно так же, как инстанциирование классов в Kotlin. Вывод от себя, в Kotlin MapStruct - это пятое колесо
А какая разница где? Все равно писать миллион присваиваний где то надо. Мапстракт справляется именно с этим. А позвать его можно и из экстеншен функции... Это ради бога.
@@AlekseyStukalov так о том-то и речь, что он, конечно, справляется... но
1. Кода в котлин я напишу +- столько же по количеству, сколько в мапстракт
2. В мапстракт вот эта история с описанием вычисляемых полей на EL ещё и несёт риск того, что при будущем рефакторинге IDE может либо просто на этот EL положить, либо криво его зарефачить. А если не дай бог препроцессору IDE вообще плевать на этот EL, то ошибки мы собирать уже будем в рантайм
@user-mj6tf8dc1d
1. Да ладно? А можно посмотреть маппинг графа, например глубиной 3, по 5 аттрибутов на каждой сущности? Мапстракт как раз весь этот код аккуратненько генерит.
2. Так EL то вообще не обязательно использовать. Пишите вычисляемые поля сразу в себя в DTO или на уровне сущности транзиентными полями и все помапится прекрасно. Это слабый аргумент ИМХО.
Очень просто, экстеншен функции для маппинга копятся постепенно. Таким образом во вложенном атрибуте вызываешь его функцию для маппинга
Record, Java движется в сторону трансформации в Delphi :)
когда пофиксят работу Jackson с record'ами тогда можно на них и перейти
Сверсии 2.15 все прекрасно работает
@@oleksandrvasylchenko316 и со снейк кейса нормально читает? именно с этим проблемы были
Что мешает писать руками конвертеры и не усложнять себе жизнь ненужными надстройками?
На самом деле ничего не мешает. Кроме дальнейшего мейтененса.
И в чем же профит этих мапперов, если нормальных проекций из базы в джаве так и не появилось
ты о чем? из репозитория можно доставать данные не только сущностей но и любой дто. Главное чтобы типы и названия полей совпадали. другое дело что это не используют ибо нужно будет слишком много этих методов делать для каждой дто. Проще достать основную сущность и замапить ее в нужное.
@@Longmanrus о да, просто супер фича
Мапперы вообще унылая возня, на порядок проще и удобнее и понятнее и быстрее обычным присваиванием делать. Я понимаю если требуется по 10 сайтов клепать в день, тогда можно эти инструменты использовать, но когда у вас ентерпрайс что вы выиграете этой возней
как раз в энтерпрайзах это и используется. Когда их за сотни маппингов. Тип и имя совпали и ничего делать не надо. И когда в объекте пару десятков полей, при ручном маппинге вообще каша читаемости будет
Только рекорды и создание руками. Всё остальное... Либы, ломбок - безумие.
Удобно, пока нет сущностей со 150ю полями..