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