Stanislav Bashkyrtsev,

зависит от приложения, где-то не возникает в них необходимости. Например, у нас приложение на базе Eclipse, там вместо мепперов активно используются адаптеры.

В веб-приложениях сложно представить как обходиться без мепперов. Там как минимум есть слой хранения данных и слой DTO для обмена данными с клиентом. В любом случае какой-то меппер нужен, хотя бы Jackson'овский. Может GraphQL как-то меняет ситуацию...

Stanislav Bashkyrtsev,

не только про сериализацию. Там можно накрутить разных правил какие атрибут сериализовывать, какие нет, каким образом (де)сериализировать ссылки на объекты, как работать с иерархиями классов и т.д. Можно объединить entity и dto в одних классах, нафигачить там и JPA, и Jasckson аннотаций. Но в этом случае Jackson будет использоваться не просто как (де)сериализатор, он будет выполнять и функции меппера.

А если entity и dto разделить, тогда, да, с Jackson задачи меппингу снимаются, он работает исключительно как (де)сериализатор. Но в этом случае нужен отдельный полноценный меппер.

localhost8080,

а зачем они схлопываются в один класс? И как они будут различаться на клиенте? Как клиент поймёт где собака, где кошка? Не знаю деталей, но я бы для каждого класса сделал свой DTO-класс: AnimalDto, CatDto, DogDto, BirdDto и мапил их один-к-одному. Возможно убирая какие-то технические поля, заменяя ссылки на идентификаторы, ...

Если логика преобразования объектов какая-то сложная, то это уже не меппер, а бизнес-логика. Или нужен какой-нибудь GraphQL, чтобы клиенты сами выбирали данные какие им нужны. Хотя по-моему даже в GraphQL структура данных сохраняется, они не схлопываются.

Ну, или даже если схлопывать, то можно сделать такой меппер (псевдокод). AnimalResponse я бы сразу переименовал в AnimalDto на случай если он и с клиента на сервер может приходить.



По крайней мере это единообразный код, которым можно замапить что угодно, а не конструкторы с десятками параметорв. И конечно я не писал бы всё это вручную, а генерил.

Это проще при написании отдельного маппера для отдельных классов. Когда этих классов сотни, когда у них много атрибутов, сложные иерархии наследования, то становится не так важно что код немного избыточный, на много важнее, что он единообразный. Например, для абстрактных классов с наследниками мы всегда пишем/генерим код с if/instanceof. Для классов без наследников генерим просто инициализацию атрибутов. Для неабстрактных классов с наследниками генерим гибридный вариант (на самом деле в шаблоне только его и нужно описать с двумя проверками: есть ли дочерние классы, абстрактный ли это класс). Методы init вынесены отдельно, чтобы можно было мапить сложные иерархии классов без дублирования кода.

Короче, при усложнении иерархии классов этот примитивный метод усложнится до совершенно неподдерживаемого состояния. А если в меппере всё разбито на map/init/create методы, то код масштабируемый на сколько угодно классов. И вообще он становится на столько примитивным, что его можно генерить, а не писать руками.

Хотя, блин, тут можно попасть в другую крайность. Я сталкивался с тем, что люди фигачат кучу каких-то фабрик, вспомогательных классов, методов, которые совершенно не нужны и только усложняют код. А потом начинаются взаимные обвинения в оверинжиниринге :)

Кстати! У вас же запрет на использование сторонних либ в рантайме? А в дизайнтайме можно использоваться что угодно? Может тот же MapStruct можно использовать? Это обычно ещё один довод в пользу кодогенераторов, что правила того же мепирования объектов описываются один раз, потом по этому описанию можно сгенерить реализацию под любые требования рантайма. У меня, например, из одних моделей генерится и Java, JavaScript код. Хотя, MapStruct вроде вынуждает засирать код аннотациями, а в случае своего кодогенератора это не нужно.

Лично мне уже на втором меппере стало бы лень их писать. Я обычно смотрю только во вторую очередь как можно написать код короче и красивее, а в первую - как можно его вообще не писать, скинуть на кодогенаратор.