Pull to refresh

Comments 10

Было бы хорошо ещё сравнить интеграцию в ef core. Automapper умеет генерировать правильные sql селекты с использованием ProjectTo

У Mapster есть аналогичная ProjectTo поддержка EF какр раз через вскольз упомянутый ProjectToType, который работает с IQueryable. Можно попробовать сравнить. Тут вопрос, будет ли, например, хорошим сравнением использованием InMemory или хочется именно данных на реальной "железной" БД? И нужно, конечно, сравнивать не "очевидные" сценарии, где маппинг явный.

Для меня и просто наличие поддержки хватает, спасибо.

Все равно все тонкости реализации всплывут только во время активного использования

В первой части статьи вы так расписывали удобство Mapster'a что в нём не надо явно конфигурацию прописывать. Но ведь в продакшене в любом случае эти правила должны быть явно прописаны, чтобы иметь возможность вызвать AssertConfigurationIsValid.
Да и про киллер-фичу с генерацией моделек у мапстера ни слова.

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

На самом деле в стороннем бенчмарке из статьи есть сравнение как раз с ручным маппингом в методе. Мне, правда, это сравнение кажется не совсем честным — например, там повсеместно используется LINQ, что очевидно будет замедлять код. Собственно, ручной маппинг там на 2-3 месте обычно. Без LINQ и на моих модельках результаты немного другие, Mapster вдвое медленнее на комплексных типах и чуть медленнее на простых.

Тест немного не корректный, потому что не учитывает время на инициализацию и конфигурацию мэпперов. Но даже в нем видно, что они не про производительность.

Да, мапперы это история скорее про организацию кода. И иногда про валидацию, например, благодаря AssertConfigurationIsValid. То есть, ручная конвертация будет в любом случае быстрее (или сопоставима по скорости в случае с кодогенерируемым маппингом).

Я для себя вижу такие потенциальные недостатки или опасности ручного маппинга:

  • В сложных моделях, когда метод конвертации зависим от пары других методов конвертации могут начаться проблемы с организацией кода и тем, где он лежит. Чаще всего с хорошей организацией моделек таких проблем не случается, но это место, где может появиться вторая реализация маппинга потому что использовали не метод, а написали свою конвертацию подмодельки.

  • (В немикросервисах) через пару лет поддержки можно обнаружить 3-4 метода конвертации одной и той же модельки в разных местах прото от того, что разработчик не нашёл существующий метод конвертвции.

  • Сценарий "добавил свойство, не протащил в конвертер" — это как раз то, что ловится в библиотеках маппинга валидацией.

Все эти риски — явная проблема качества и организации кода, так что можно просто никогда не ошибаться и этих проблем не будет.

Да, именно так. Мэпперы это про упрощение разработки и поддержки проекта.

Mapster с кодогенерацией даёт такую же скорость как и при ручном маппинге.

Единственное что проекции не будут работать, но тут понятно по каким причинам.

Sign up to leave a comment.

Articles