Комментарии 10
Было бы хорошо ещё сравнить интеграцию в ef core. Automapper умеет генерировать правильные sql селекты с использованием ProjectTo
У Mapster есть аналогичная ProjectTo поддержка EF какр раз через вскольз упомянутый ProjectToType, который работает с IQueryable. Можно попробовать сравнить. Тут вопрос, будет ли, например, хорошим сравнением использованием InMemory или хочется именно данных на реальной "железной" БД? И нужно, конечно, сравнивать не "очевидные" сценарии, где маппинг явный.
В первой части статьи вы так расписывали удобство Mapster'a что в нём не надо явно конфигурацию прописывать. Но ведь в продакшене в любом случае эти правила должны быть явно прописаны, чтобы иметь возможность вызвать AssertConfigurationIsValid.
Да и про киллер-фичу с генерацией моделек у мапстера ни слова.
Было бы интересно увидеть сравнение производительности с кодом без использования что первого, что второго.
На самом деле в стороннем бенчмарке из статьи есть сравнение как раз с ручным маппингом в методе. Мне, правда, это сравнение кажется не совсем честным — например, там повсеместно используется LINQ, что очевидно будет замедлять код. Собственно, ручной маппинг там на 2-3 месте обычно. Без LINQ и на моих модельках результаты немного другие, Mapster вдвое медленнее на комплексных типах и чуть медленнее на простых.
Тест немного не корректный, потому что не учитывает время на инициализацию и конфигурацию мэпперов. Но даже в нем видно, что они не про производительность.
Да, мапперы это история скорее про организацию кода. И иногда про валидацию, например, благодаря AssertConfigurationIsValid. То есть, ручная конвертация будет в любом случае быстрее (или сопоставима по скорости в случае с кодогенерируемым маппингом).
Я для себя вижу такие потенциальные недостатки или опасности ручного маппинга:
В сложных моделях, когда метод конвертации зависим от пары других методов конвертации могут начаться проблемы с организацией кода и тем, где он лежит. Чаще всего с хорошей организацией моделек таких проблем не случается, но это место, где может появиться вторая реализация маппинга потому что использовали не метод, а написали свою конвертацию подмодельки.
(В немикросервисах) через пару лет поддержки можно обнаружить 3-4 метода конвертации одной и той же модельки в разных местах прото от того, что разработчик не нашёл существующий метод конвертвции.
Сценарий "добавил свойство, не протащил в конвертер" — это как раз то, что ловится в библиотеках маппинга валидацией.
Все эти риски — явная проблема качества и организации кода, так что можно просто никогда не ошибаться и этих проблем не будет.
Mapster с кодогенерацией даёт такую же скорость как и при ручном маппинге.
Единственное что проекции не будут работать, но тут понятно по каким причинам.
Сравнение AutoMapper и Mapster