Интересный спор у нас произошел на работе. Один из программистов начал проталкивать AutoMapper, это фигня, которая автоматически может копировать данные из одного объекта в другой, даже если их классы разные. Маппинг происходит автоматически, если имена полей совпадают, но можно и конфигурировать, если имена не совпадают.
Преимущество использования автомаперов - не нужно писать код типа:
dst.Field1 = src.Field1
dst.Field2 = src.Field2
dst.Field3 = src.Field3
Неужели так сложно написать такой код и нужно делать что-то автоматически?
Ну хорошо, лентяи не хотят писать подобное, начали обсуждать, стоит ли переходить на автомапинг.
Преимущество:
1. Не нужно писать относительно простой код
Как я понял, недостатки:
1. Если переименовать поле в одном объекте, то маппинг ломается и вы это можете не заметить и сломаете приложение. То есть вероятность ошибки увеличивается
2. Если где-то есть конфигурация, то вы хрен ее найдете. Вы видите маппинг, но просто навести на что-то мышкой и нажать F12 не получится. Придется руками искать маппинг старинным поиском по всему коду. Простите, но ради небольшой экономии написать простые пару строчек я должен вернуться в прошлый век и не могу искать по ссылкам?
3. Если ты видишь конфигурацию маппинга и хочешь изменить ее, вполне логично было бы найти, где маппинг используется и не сломается ли ни один из них. Если используем самописный код, то просто наводим на метод и смотрим референсы. В случае с Automapper снова нет возможности ничего найти и вероятность сломать код огромная.
Для меня эти три пункта просто нереально огромная проблема, я не перейду ни на какой автоматический маппинг, если он экономит мне время на банальных операциях, но увеличивает вероятность ошибки кода. Если такая проблема написать простой код, то лучше бы написали генератор кода для маппинга. Сгенерировал, скопировал себе в код и забыл. По крайней мере код будет надежный, легко поддерживаемый, легко находимый ...
Что ты думаешь про автомаппинг? Я им не пользовался сам, но просто из обсуждения сложилось ощущение, что это полное дерьмо. Да, я экономлю на том, что не нужно писать досточно простые операции присвоения, но при этом получаем гемморой, который добавляет больше проблем, чем экономии. Можешь ты расскажешь что-то интересное и полезное.
P.S. Если честно, то я вообще не понимаю архитектуры, где нужно маппить объекты. Мне вообще этот подход кажется неверным.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Автомаппер ужасное зло. У нас используется сплошь и рядом, для конвертаций обьектов которые на бекенде в обьекты которые на фронтэнде. Не спрашивай зачем, архитекторы так нарисовали.
Так вот. Маппить обьект в обьект еще не страшно, там если что-то сломалось - найти где это и починить достаточно просто. Но вот когда маппишь сложные структуры, например, обьекты с коллекциями в которых находятся обьекты которые тоже маппятся, то вот тут начинается жесть. Ведь ты можешь удалять обьекты из коллекции, модифицировать их и добавлять. И во время маппинга у нас была куча проблем. И лишние обьекты появлялись и нулы пролезали и мержилось криво. И если нулы отловить и тут тоже не сильно большая проблема, то кривой маппинг ударяет по бизнес логике и после нескольких раундов калькуляций получаешь неправильный результат. И сиди ищи почему посчиталось неправильно.
Короче, лучше просто написать бойлерплейт с ручным маппингом, чем разбираться с автомагией.
А как не маппить объекты? В базе нормализированная модель, одна бизнес сущность можеть быть разбита на кучу таблиц по правилам нормализации/реляционной теории. В слое бизнес логики надо работать с бизнес (Domain) моделями. На фронт энде в 75-90% случае бизнес модель подойдёт, но иногда это не удобно или в разных местах надо немного другая модель, тут уже View (DTO) модели помогают. На счёт маппинга я использую или AutoMapper, или удобный способ с помощью расширяющих методов в C# что-то вроде ".ToMyDomainModel(), .ToMyViewModel(), .ToMyEntityModel()", это помогает просто вынести маппинг в отдельное место на захламляя код, маппинги часто бывают большими и когда в коде который реализует какую-то задачу его захламляет маппинг я этого не люблю, особенно в слое репозитория всё время куча маппингов с Entity моделей в Domain при выборке из базы и наоборот из Domain в Entity при сохранении в базу. С Dapper подход немного другой, он маппит сам.
Считаю автомаппер не нужным делом. Не вижу реальных сфер применения.
Михаил, можно и без автомаппера облегчить себе жизнь. Например писать под нужные классы свои экстеншены , возвращающие опять таки нужный замапленный класс. Ал-я маппинг для бедных.
Автомаппер чаще всего юзаем в вебАпи проектах. Особенно помогает при использовании с шаблоном DTO.
Одно дело речь идёт о трёх переменных, а что если есть сложная структура разбитая на сотни таблиц, с минимум сотней переменных в ней? Мапить просто присвоение в одном месте ладно, а что если проект не двухминутный и у тебя минимум 20 ендпоинтов? А ведь тебе нужно не только строки присваивать, но и работать хэшмапами, списками из классов и многое другое.
Увы, но я бы сказал все зависит от сложности проекта. Иногда автомаппер это именно та вещь, которая тебя спасает.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
