DTO mapper как услуга

Question

Я работаю над проектом, который использует auto mapper в качестве метода перевода объектов домена для просмотра моделей.

В настоящее время он находится за IMapperService. Текущая реализация этой службы переадресовывает вызовы в auto mapper (та же подпись метода).

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

Однако я решил, что сопоставления должны быть переписаны по другим трюкам приложения.

Я думаю, что маловероятно, что реализация auto mapper будет заменена на полпути через проект.

Я хочу удалить зависимость от этой службы и плотно связать (никогда не думал, что я так сказал) мои контроллеры для автоматического сопоставления, поскольку я решил, что логика отображения привязана к автокартеру в любом случае.

Неужели кто-либо когда-либо абстрагировал вызовы карты кард-карт в службу, если это так; вы когда-либо меняли картупер наполовину или в конце проекта?

Является ли абстрагирование вызовов автоматического отображения в службу кажутся излишними?

Answer 1

Я использую подход, который вы упомянули при использовании AutoMapper, я предпочитаю программировать интерфейс по мере возможности. Вызывающий код (контроллер/служба) должен заботиться только о том, «что» (X сопоставляется с Y), а не «как» (AutoMapper отображает X в Y).

Если вероятность того, что вы можете отключить AutoMapper для чего-то другого, низкая, и вы не хотите вводить пользовательскую услугу, тогда вы можете посмотреть на ввод IMappingEngine. Это экономит вызовы для статической функции Mapper.Map и может быть легко высмеивается для целей тестирования.

Answer 2

В наших контроллерах/службах отображение обычно представляет собой один вызов AutoMapper Map. Это упростит изменение, если мы хотим использовать другой механизм отображения. Более сложные изменения касались бы самих сопоставлений.

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