Comments 42
Все эти модные мапперы по большу счету выносят ошибки compile-time в runtime — что есть плохо. Это не считая дополнительных расходов на то что они пельменят/мерджат/конвертят в рантайме объекты.
Ну, а вбить getter/setter с помощью multicursor (как в sublime text) можно за 10-30 секунд для сколько угодно количества полей (если имена getter/setter совпадают, конечно же — ну впрочем такое же условие у большенства мапперов, ну а расходы на конфигурацию маппера гораздо больше чем поменять аналогичный get/set).
Ну, а вбить getter/setter с помощью multicursor (как в sublime text) можно за 10-30 секунд для сколько угодно количества полей (если имена getter/setter совпадают, конечно же — ну впрочем такое же условие у большенства мапперов, ну а расходы на конфигурацию маппера гораздо больше чем поменять аналогичный get/set).
По моему опыту, в процессе написания простыней пересечевания свойств из одного объекта в другой, вероятность допустить ошибку довольно легко — забыть про какое то свойство например, засетить не то что нужно (типы случайно совпали, компилятор ничего не сказал).
А потом искать все эти тупые ошибки. А еще попробуйте представьте как мержить коллекции бинов… В моем первом проекте было именно так, и использовать дозер мы стали не просто так. Интересно было бы узнать про сложные условия конфигурации мапперов. @Mapping аннотацию сложно поставить? Или зарегистрировать конвертер типов DateTime в Date 1 раз и забыть об этом? По поводу дополнительных расходов в рантайме, они ничтожно малы и ими можно пренебречь. Как я уже проверял 50000 операций маппинга за 8 секунд для не самого простого объекта.
А потом искать все эти тупые ошибки. А еще попробуйте представьте как мержить коллекции бинов… В моем первом проекте было именно так, и использовать дозер мы стали не просто так. Интересно было бы узнать про сложные условия конфигурации мапперов. @Mapping аннотацию сложно поставить? Или зарегистрировать конвертер типов DateTime в Date 1 раз и забыть об этом? По поводу дополнительных расходов в рантайме, они ничтожно малы и ими можно пренебречь. Как я уже проверял 50000 операций маппинга за 8 секунд для не самого простого объекта.
Согласен с предыдущим пользователем. Имеем несколько крупных проектов EAI. А это сплошной меппинг между огромным количеством структур, в основном xml. После большого количества итераций было установлено, что тупой джавовский меппинг объектов удобнее в поддержке в 10 раз, чем все остальные способы. Пользовались и графическими мепперами, и различными фреймворками и xslt. Приходилось писать большое число тестов для мепперов (а написание теста по трудоемкости в 2 раза превышает написание самого меппера). Основные проблемы:
1. Несовместимость объектов. Приходилось писать большое число custom-мепперов с достаточно сложной логикой, вдвойне усложненной самими ограничениями фреймворка.
2. Не type-safe-ность. Когда сверху «спускали» новую версию интерфейсов, проводилась огромная работа по установлению какие мепперы задеты изменением.
В итоге решение было — генерация java-объектов через JAXB с последующим ручным меппингом. Плюсы налицо: полная свобода, type-safe, простая возможность custom-логики, поддержка IDE (попапы с полями здорово помогают), повторное использование мепперов в разных структурах, моментальное отслеживание изменений. Для ускорения работы и более чистого кода используем xtend.
1. Несовместимость объектов. Приходилось писать большое число custom-мепперов с достаточно сложной логикой, вдвойне усложненной самими ограничениями фреймворка.
2. Не type-safe-ность. Когда сверху «спускали» новую версию интерфейсов, проводилась огромная работа по установлению какие мепперы задеты изменением.
В итоге решение было — генерация java-объектов через JAXB с последующим ручным меппингом. Плюсы налицо: полная свобода, type-safe, простая возможность custom-логики, поддержка IDE (попапы с полями здорово помогают), повторное использование мепперов в разных структурах, моментальное отслеживание изменений. Для ускорения работы и более чистого кода используем xtend.
Приходилось писать большое число тестов для мепперов (а написание теста по трудоемкости в 2 раза превышает написание самого меппера)
Мы слишком ленивые чтобы писать юнит тесты в текущем проекте =) Но есть одна идея как можно было бы простестить весь маппинг особо не напрягаясь… По сути, при автоматическом маппинге декларативно описывается, что куда мапить Значит будет достаточно проверить чтобы все поля замапились. И вот как это можно сделать. Допустим есть DTO и есть VO на которую мапим. 1) Заполняем все поля DTO, а так же ее чайлдов — случайными данными. Это можно сделать рефлешеном, используя тот же common-beanutils. 2) Мапим. 3) Проверям что на VO — все поля заполнены, тем же common-beanutils. Таким тестом проверим самую распространенную ошибуку, когда поля в DTO и VO случаной назвали по разному, и автоматический маппинг не сработал (ошибки он тоже не выдаст в этом случае). Если же присутствует аннотация
@Mapping и поля на корое она ссылается нет — то будет ошибка во время маппинга. Таким образом можно обойтись одним (хотя и сложным) тестом.
Полностью согласен с предыдущим оратором (rtorsten) — object mappers, чаще всего, не привносят ничего хорошего. И добавляют множество проблем, если понадобится (а это в 99% случаев так) добавить какую-то логику конвертации, навскидку country в country code, true/false в 1/0, или любой dictionary lookup.
Например, после пары лет эволюции в проекте дозер мэппер большой частью состоял из custom mappers, и понять весь процесс мэппинга не представлялось возможным. При переходе на тупые и деревянные plain java mappers вида a.setField(b.getField()), любой девелопер мог поддерживать меппинги. Да, выглядит ужасно. Да, копипаста. Но очень дешевые изменения и очень, очень быстрый меппинг. И этот кусок кода в проекте лежит обособленно и не мешает. И compile-time проверки.
Любители красоты могут попробовать груви, пожертвовав быстродействием.
Plain java подход не требует навешивания аннотаций. Это может быть критично, если доменная модель, как это любят в энтерпрайзе, генерится из xsd с помощью jaxb.
Edit: и не забываем про final объекты, у которых вообще может не быть сеттеров.
Например, после пары лет эволюции в проекте дозер мэппер большой частью состоял из custom mappers, и понять весь процесс мэппинга не представлялось возможным. При переходе на тупые и деревянные plain java mappers вида a.setField(b.getField()), любой девелопер мог поддерживать меппинги. Да, выглядит ужасно. Да, копипаста. Но очень дешевые изменения и очень, очень быстрый меппинг. И этот кусок кода в проекте лежит обособленно и не мешает. И compile-time проверки.
Любители красоты могут попробовать груви, пожертвовав быстродействием.
Plain java подход не требует навешивания аннотаций. Это может быть критично, если доменная модель, как это любят в энтерпрайзе, генерится из xsd с помощью jaxb.
Edit: и не забываем про final объекты, у которых вообще может не быть сеттеров.
И добавляют множество проблем, если понадобится (а это в 99% случаев так) добавить какую-то логику конвертации, навскидку country в country code
Может в дозере это и проблема, а в java-object-merger это можно сделать аннотацией типа:
@Converter(ContryToCode.class), или конвертором типов.true/false в 1/0,
Можно 1 раз зарегисрировать конвертер типов с соответсвующей логикой пребзования булевских значений в int. Не вижу никакой сложности.
dictionary lookup.
Аналогично, пишем конвертер вашего энума в строку и регистрируем его, если я правильно понял о чем речь.
Проблема в ручном засечевании в том, что вызов логики конвертации у вас будет дублироваться для многих полей. А с маппером можно часто загеристрировать 1 конвертер типов один раз в одном месте, и забыть об этом — т.к. отныне он будет использоваться.
Например, после пары лет эволюции в проекте дозер мэппер большой частью состоял из custom mappers
Вероятно это особенность вашего проекта. У меня же был другой опыт, что очень малый процент из всех полей нуждается в какой либо конвертации. В основом это — перегнать как есть, чуть реже — настроить конвертацию на уровне типов, еще реже — осбенная конвертация на уровне отдельных полей. Поэтому утверждать о бесполезности инструмента все же не стоит. Лучше задуматься о том, как модифицировать инструмент таким образом, чтобы он оказался полезным и в вашем случае.
Это может быть критично, если доменная модель, как это любят в энтерпрайзе, генерится из xsd с помощью jaxb.
Если все классы учавствующие в маппинге генерируемые (такого не встречал), тогда этот инструмент конечно не подойдет. Но если хотя бы один из слоев, например слой представления, пишется вручную, то на его классах можно навесить аннотации, и маппинг будет работать в обе стороны.
Если БО генерируются в рантайме другого выхода нет.
После появления в дозере аннотации @Mapping с облегчением вздохнул… и выкинул все лишние геттеры/сеттеры из presentation- и business- объектов. Отсюда вопрос автору топика: Ваш велосипед умеет переносить внутреннее состояние между объектами, минуя геттеры/сеттеры?
Сейчас — не умеет. Для работы со свойствами используется библиотека common-beanutils. Но пожалуй в новой версии добавлю маппинг на открытые поля.
Нет-нет. Вы не совсем поняли. Речь идет не об открытых, а именно о закрытых, private полях. Проведите параллель между object/object мэппином и object/database мэппином, таким, например, как JPA.
В JPA, к счастью, не возбраняется инициализация приватных полей сущности «напрямую». Это может на первый взгляд показаться насильственным нарушением правил инкапсуляции. Но при более внимательном рассмотрении все оказывается с точностью до наоборот. Именно способность фреймворка добраться до приватных полей напрямую позволяет нам убрать все лишние геттеры/сеттеры, а значит защитить внутреннее состояние объекта от внешнего client-кода.
В JPA, к счастью, не возбраняется инициализация приватных полей сущности «напрямую». Это может на первый взгляд показаться насильственным нарушением правил инкапсуляции. Но при более внимательном рассмотрении все оказывается с точностью до наоборот. Именно способность фреймворка добраться до приватных полей напрямую позволяет нам убрать все лишние геттеры/сеттеры, а значит защитить внутреннее состояние объекта от внешнего client-кода.
Библиотека должна быть представлена в одном из репозиториев Maven, иначе никакие промо статьи ей не помогут.
Если, скажем, IDEA не может понять куда эта библиотека копирует поле определенного обьекта, то ей решительно нельзя пользоваться как и всеми ей подобными. Со временем становится не понятно какие поля используются, какие нет, как получилось конкретное поле и тому подобное без изучения конфига меппинга. При наивном подходе нажал find usages и готово.
И да, соглашусь с комментаторами выше — ручное копирование полей никогда не было узким местом разработки.
И да, соглашусь с комментаторами выше — ручное копирование полей никогда не было узким местом разработки.
Если, скажем, IDEA не может понять куда эта библиотека копирует поле определенного обьекта, то ей решительно нельзя пользоваться как и всеми ей подобными.
Как же мы тогда пользуемся? Удивительно.
Ребята, о чем вы спорите? А давайте отменим маппинг полей бд на сущность. Будет к примеру приходить датасет а вы с него ручками повытягиваете все поля и просетите в объект. А что… зато полный контроль. Только почему то все от этого пришли к автоматическим мапперам. Дураки наверное.
Да можно же запилить интеграцию иде под конкретную либу. Расширить Find Usages.
Разве Идея не умеет интеграции с Хибернейтом?
Был бы кто-нибудь из создателей проекта, которому не лень этим заниматься, и кто знает кишки двух основных IDE.
Не беспокойтесь так :-)
Чисто мое имхо — использовать нечто, не умеющее интеграцию с иде (или иде, не умеющее интеграцию с этим) — не буду, пока интеграция не появится либо я не прикручу ее самостоятельно.
Разве Идея не умеет интеграции с Хибернейтом?
Был бы кто-нибудь из создателей проекта, которому не лень этим заниматься, и кто знает кишки двух основных IDE.
Не беспокойтесь так :-)
Чисто мое имхо — использовать нечто, не умеющее интеграцию с иде (или иде, не умеющее интеграцию с этим) — не буду, пока интеграция не появится либо я не прикручу ее самостоятельно.
Да можно же запилить интеграцию иде под конкретную либу. Расширить Find Usages.
Согласен.
Чисто мое имхо — использовать нечто, не умеющее интеграцию с иде (или иде, не умеющее интеграцию с этим) — не буду, пока интеграция не появится либо я не прикручу ее самостоятельно.
Идея вас разбаловала я вижу :) А как же написание исходного кода в блокноте, как же хардкор? :)
«использовать нечто, не умеющее интеграцию с иде (или иде, не умеющее интеграцию с этим) — не буду»
ZK framework уже давно просят добавить, а его всё нет. Но это не мешает мне кодить в IDEA с использованием оного.
PS: «иде» — фи.
ZK framework уже давно просят добавить, а его всё нет. Но это не мешает мне кодить в IDEA с использованием оного.
PS: «иде» — фи.
PS: «иде» — фи.IDE-фикс ;-)
А я вот пользуюсь меппером и плююсь. Можете почитать другие каменты. Многие плюются.
И причем тут БД? find usages для колонки вы как себе представляете? Это же сущность вне кодовой базы.
И причем тут БД? find usages для колонки вы как себе представляете? Это же сущность вне кодовой базы.
Как хорошо, что я не пишу такой enterprise где в каждом слое своя модель. Голову бы поотвинчивать тому, кто придумал всякие VO, DTO и прочую жуткую муть.
Если вы знаете способ как проще организовывать архитектуру enterprise, то поделитесь с общественностью. Может вы гений а мы все идиоты :)
Да дело не только в развесистом enterprise, иногда даже просто формирование данных сложного отчета для передачи во view требуется DTO, которое бы особым образом собрало воедино разрозненные данные. Тянуть логику непосредственно во view страх и ужас, ибо поддерживать потом такое просто невозможно.
Да нет. Просто стараться не плодить сущностей. В конечном итоге наши данные, это и есть наши данные, стаховые полисы, клиенты, машины, иски и т.д. Это основа всей аппликации, самый нижний слой. Ну а на нем сидит все остальное. А если потом нам нужен клиент, только вот «без такого поля», или клиентомашина — значит наверное мы делаем что — то не так и надо хорошо задуматься зачем нам это надо. Исключения это общие форматы, которые позволит передать данные дальше (XML или json).
Имхо, это проблема самой Жавы, что элементарные вещи типа мапинга «наивным способом» реализуются откровенно плохо (тормозит, плохо рефакторится), а не наивным способом ява обрастает метаязыком на аннотациях, теряя и свою сущность, и поддержку тулзов которые умеют автоматически анализировать жаву (жаву, а не твой метаязык, черт знает как вбитый в аннотации). И то, что все «посторонние» решения типа сабжевого маппера выглядят как прикрученные сбоку костыли — нет способа модифицировать синтаксис базового языка, не потеряв интеграции с иде и другими автотулзами.
Заинтриговали… А а в каком языке можно реализовать маппинг изящнее?
Не понял. Как раз тупое пересечевание свойств как в примере, работает супер быстро.
Тулзы можно научить анализировать аннотации точно так же как и обычный код, ибо аннотации это часть языка.
Эм… Преположим что есть плагин к ide который облегчает пользоваться некой библиотекой X версии N. Выходит версия библиотеки N + 1. Думаете если в бибиотеке нет аннотаций а только классы, то плагин не нужно будет как то менять и приспосабливать к версии N + 1?
элементарные вещи типа мапинга «наивным способом» реализуются откровенно плохо (тормозит, плохо рефакторится)
Не понял. Как раз тупое пересечевание свойств как в примере, работает супер быстро.
а не наивным способом ява обрастает метаязыком на аннотациях, теряя и свою сущность, и поддержку тулзов которые умеют автоматически анализировать жаву (жаву, а не твой метаязык, черт знает как вбитый в аннотации)
Тулзы можно научить анализировать аннотации точно так же как и обычный код, ибо аннотации это часть языка.
И то, что все «посторонние» решения типа сабжевого маппера выглядят как прикрученные сбоку костыли — нет способа модифицировать синтаксис базового языка, не потеряв интеграции с иде и другими автотулзами.
Эм… Преположим что есть плагин к ide который облегчает пользоваться некой библиотекой X версии N. Выходит версия библиотеки N + 1. Думаете если в бибиотеке нет аннотаций а только классы, то плагин не нужно будет как то менять и приспосабливать к версии N + 1?
Сразу бросилось в глаза. Кликабле
Добавил к себе. Вроде работает как надо, пока серьёзных проблем не нашёл. То, что надо. Спасибо автору!
Только от себя добавлю: вам страничка для библиотеки не помешала бы: с туториалом, с нормальной документацией и разными примерами. На английском, конечно же.
Только от себя добавлю: вам страничка для библиотеки не помешала бы: с туториалом, с нормальной документацией и разными примерами. На английском, конечно же.
Спасибо! Не забудьте обновится до версии 0.8.1. Насчет туториала да, буду что-то думать… Если будут какие-то проблеммы или вопросы, пишите в Discussions на страничке проекта. Возможно туториал будет там же в Wiki.
Ну вот вчера как раз сидел, разбирался. Когда нужно замаппить String name на String name, то проблем не возникает. Когда нужно замаппить что-то посложнее, а особенно из трёх полей сделать одно — то возникают непонятки. У вас в библиотеке это всё есть, да, но вот разбираться только лишь на основе исходников и обрывков JavaDoc-ов это не так то уж и лекго :) я-то сделал, что мне надо было, но это всё выглядело как блуждание в потёмках :) Так что моя просьба как от пользователя: просто приведите пару примеров с кодом из обычной жизни, где можно будет увидеть, как и в каких случаях можно использовать все аннотации. В остальном всё гуд. Спасибо ещё раз.
Кстати, код распространяется под Apache Licence, да? Это тоже стоит указать где-то на видном месте. Так как для больших корпораций это самый главный вопрос при выборе библиотек :)
Кстати, код распространяется под Apache Licence, да? Это тоже стоит указать где-то на видном месте. Так как для больших корпораций это самый главный вопрос при выборе библиотек :)
message deleted
В одном проекте данные из БД получали в Entity-объекты с ManyToOne сущностями, это было оправдано, т.к. «обналичивание» ссылочных сущностей с большой вероятностью обеспечивалось вторичным кешем. Далее они мапились в практически плоские сущности бизнес слоя, которые мапились на почти идентичные объекты для JAXB.
Мапперами стали интересоваться после того, как нахватали несколько NPE, в т.ч. с продакшена, когда вложенное свойство getA().getB().getC() сетилось в setABC() без проверки на нулл getA() и getA().getB().
А это уже, товарищи, чистый рантайм.
Один NPE поймали после рефакторинга — переноса свойства в ссылочную сущность.
Плюс одновременно действовали сервисы разных версий, где JAXB отличались добавлением/удалением свойств, до маппера тупо копипастили и таких копий было масса.
Поэтому не соглашусь, что маппер это зло, а сетфромгет это наше все.
Мапперами стали интересоваться после того, как нахватали несколько NPE, в т.ч. с продакшена, когда вложенное свойство getA().getB().getC() сетилось в setABC() без проверки на нулл getA() и getA().getB().
А это уже, товарищи, чистый рантайм.
Один NPE поймали после рефакторинга — переноса свойства в ссылочную сущность.
Плюс одновременно действовали сервисы разных версий, где JAXB отличались добавлением/удалением свойств, до маппера тупо копипастили и таких копий было масса.
Поэтому не соглашусь, что маппер это зло, а сетфромгет это наше все.
Мы эту проблему когда-то решили переходом на groovy и, соответственно, записью вида:
def some = a?.b?.c
в принципе, такие вещи должны быть покрыты тестами, независимо от того, какой способ используется.
В теории да, но на практике, юнит тесты на трансляторы, особенно если сущности большие и сложные — будут по коду в несколько раз сложнее самого транслятора (того самого тупого кода). Т.к. нужно проверить много вариантов: если большая вложнность getA().getB().getC() — 1) проверить если есть A B C, потом что A B есть, а C — null, и т.д. Да, безусловно надежность будте повышаться, но ценой долгого выпиливания юнит тестов. И если сроки поджимают будет скорее всего не до юнит тестов.
Согласен на все 100%. Там где есть человеческий фактор надо постраховываться.
Я делаю тесты так заполняю объект А рандомным филером (есть масса библиотек), маплю на объект Б, потом обратно на А',
затем сравниваю А и А' equals билдером, исключая непамируемые поля.
Для случая с маппером можно тест автоматизировать — сделать цикл по коллекции маппируемых классов и проделать тетовые дейиствия через рефлексию
Я делаю тесты так заполняю объект А рандомным филером (есть масса библиотек), маплю на объект Б, потом обратно на А',
затем сравниваю А и А' equals билдером, исключая непамируемые поля.
Для случая с маппером можно тест автоматизировать — сделать цикл по коллекции маппируемых классов и проделать тетовые дейиствия через рефлексию
Sign up to leave a comment.
java-object-merger — больше чем просто маппер объектов