Какие вообще обьектные мапперы сейчас используют, или все пишут свои велосипеды? Под "обьектными" имеются ввиду мапперы между скажем слоем DTO и бизнес моделью и наоборот. Я видел множество примеров, когда такие мапперы писались самостоятельно (с помощью рефлексии, когда поля маппились на основании своих названий), либо есть библиотеки типа http://automapper.org/. Кто как к этому подходит? Задача с теми-же DTO состоит к примеру в сборке класса CreditCard(), где из пришедших полей в DTO надо отфильтровать различные символы (скажем пробелы, -, / итп), насколько сторонние библиотеки это дело облегчают?

Здравствуйте, Stalker., Вы писали:

S> насколько сторонние библиотеки это дело облегчают?

Положим, у вас есть преогромный класс Mapper, с кучей статических методов вида MapToDTO и MapFromDTO. Или даже по мапперу на каждую пару модель-ДТО. Каждый метод — по сути простой object initializer, где автодополнение вам подскажет- что еще не замаппили, а контроль типов позволит при компиляции проверить корректность маппера.

Теперь возьмем FastMapper. Когда он падает в рантайме — он не даёт внятной диагностики, что где упало. Когда вы пишете для него выражения маппинга вида .MapField(d =>d.Id, d=>d.Id), вы не можете написать там "?.", потому что маппер это не поддерживает. Вы не можете воспользоваться автоподсказкой IDE, чтобы увидеть, какие еще поля не замаплены. Если проект скомпилировался, это еще не значит, что автомаппер нормально отработает в рантайме.

В общем, автоматические мапперы суть зло и пользоваться ими не надо.

Здравствуйте, Stalker., Вы писали:

S>Какие вообще обьектные мапперы сейчас используют, или все пишут свои велосипеды? Под "обьектными" имеются ввиду мапперы между скажем слоем DTO и бизнес моделью и наоборот. Я видел множество примеров, когда такие мапперы писались самостоятельно (с помощью рефлексии, когда поля маппились на основании своих названий), либо есть библиотеки типа http://automapper.org/. Кто как к этому подходит? Задача с теми-же DTO состоит к примеру в сборке класса CreditCard(), где из пришедших полей в DTO надо отфильтровать различные символы (скажем пробелы, -, / итп), насколько сторонние библиотеки это дело облегчают?

Автомапперы — несомненное зло. Я знаю два изящных решения проблемы преобразования моделей:

— переходить на Scala. Она поддерживает именованные параметры при вызове методов и конструкторов, так что при использовании конструктора для создания и наполнения объекта получается надежное решение: добавление нового поля в конструктор гарантированно вызывает ошибку компиляции. Перепутать параметры местами или забыть что-то указать тоже не получится.
— использовать билдеры. ручные или генеренные через lombok. Ошибка будет уже на этапе выполнения, но сложных тестов на простые конверторы можно уже не писать.

Здравствуйте, Stalker., Вы писали:

S>Какие вообще обьектные мапперы сейчас используют, или все пишут свои велосипеды? Под "обьектными" имеются ввиду мапперы между скажем слоем DTO и бизнес моделью и наоборот. Я видел множество примеров, когда такие мапперы писались самостоятельно (с помощью рефлексии, когда поля маппились на основании своих названий), либо есть библиотеки типа http://automapper.org/. Кто как к этому подходит? Задача с теми-же DTO состоит к примеру в сборке класса CreditCard(), где из пришедших полей в DTO надо отфильтровать различные символы (скажем пробелы, -, / итп), насколько сторонние библиотеки это дело облегчают?

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

subj