Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение
Согласен на все 100%. Там где есть человеческий фактор надо постраховываться.
Я делаю тесты так заполняю объект А рандомным филером (есть масса библиотек), маплю на объект Б, потом обратно на А',
затем сравниваю А и А' equals билдером, исключая непамируемые поля.

Для случая с маппером можно тест автоматизировать — сделать цикл по коллекции маппируемых классов и проделать тетовые дейиствия через рефлексию
В одном проекте данные из БД получали в Entity-объекты с ManyToOne сущностями, это было оправдано, т.к. «обналичивание» ссылочных сущностей с большой вероятностью обеспечивалось вторичным кешем. Далее они мапились в практически плоские сущности бизнес слоя, которые мапились на почти идентичные объекты для JAXB.
Мапперами стали интересоваться после того, как нахватали несколько NPE, в т.ч. с продакшена, когда вложенное свойство getA().getB().getC() сетилось в setABC() без проверки на нулл getA() и getA().getB().
А это уже, товарищи, чистый рантайм.

Один NPE поймали после рефакторинга — переноса свойства в ссылочную сущность.
Плюс одновременно действовали сервисы разных версий, где JAXB отличались добавлением/удалением свойств, до маппера тупо копипастили и таких копий было масса.

Поэтому не соглашусь, что маппер это зло, а сетфромгет это наше все.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность