Как мы перенесли ответственность за поддержку мапперов моделей на KSP

[Lewigh]

Понимаете, у вас проблема не с маппером а с тем что развели батальон различных слоев которые между собой нужно маппить. Вам зачем на мобильном приложении четыре слоя данных, вы от кого защищаетесь и абстрагируетесь? На backend нужны транспортные модели потому что могут быть разные клиенты и транспорты и самое главное - версии, бизнес модели для БД, и наконец backend ходит в интеграцию где используем не свои модели.

А вы в приложении что со всеми этими четырьмя слоями делаеме, от кого абстрагируетесь, от собственного экрана? Я понимаю ну допустим транспортные DTO как точка интеграции с backend потому что мб вы это не контролируете(и это плохо). Но остальные то к чему? Делать вид что мобильное приложение это backend сервис? К чему городить четыре слоя три из которых бесполезные создавая себе проблему чтобы потом героически превозмогать?

[swame]

Cиндром второй системы

[Tarson]

Блин, я думал, что здесь про Kerbal Space Program(

[mst_72]

Мапперы - это “мёртвая зона”: они пишутся механически, но при этом легко ломаются и не приносят никакой ценности бизнесу.

Это прекрасно. Бизнес. Value... Раз мы такие бизнес-ориентированные - нафига писать маперы? Или может в ним есть некая ценность? Просто формулируемая не "здесь и сейчас" и как часть скажем некоего параметра maintenability?
По поводу общей сложности и синдрома второй системы мне добавить нечего.
Но про бизнес - это просто прекрасно.
Кстати - надо бы ещё и про "карбоновый след" не забыть добавить в следующей статье и словить бинго.