Pull to refresh

Comments 9

Поясните, пожалуйста, если мы не используем внешних зависимостей при маппинге (они 100% отправляют нас в ад), то чем не подходит тривиальная инициализания маппингов в bootstrapper-классе? Пока нам не нужно тестировать сами маппинги мне не видно причины, заставляющей нас иметь разную реализацию для теста и приложения той части бутстраппера, которая отвечает за маппинги. Подскажите, где я не прав.
Если вкратце — то вы правы.

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

Опять-таки, если маппинги заковыристые (что, заметим, тоже не очень правильно, но иногда без этого не обойтись), то для теста бывает полезнее их исключить (чтобы не подбирать исходные данные так, чтобы после маппинга получилось то, что нам нужно), и тогда удобно просто замокать весь маппер целиком.
Добавьте пример того, как в итоге используете этот механизм.
А чем тот пример кода, который над хабракатом, не подходит?
тогда не понял. подумал OKEIResolver это некий хелпер, который непонятно где вызывается.
OKEIResolver — это обработчик, который вызывается при маппинге конкретного атрибута. Вас интересует пример для него?
Да, интересно.
CreateMap<Dto, Data>()
.ForMember(p => p.Id, m => m.Ignore())
.ForMember(p => p.Quantity, m => m.MapFrom(d => d.Amount))
.ForMember(p => p.UnitId, m => m.ResolveUsing<OKEIResolver>().FromMember(p => p.okeiCode))
Поскольку прошло больше пяти лет, возможно кому-то пригодится небольшая добавка для случая .Net Core.
Тут всё очень просто и функционально — всего лишь надо установить nuget package
AutoMapper.Extensions.Microsoft.DependencyInjection, добавить профили с маппингом
в проекты решения
public class DataAccessMappingProfile : Profile
{
   public DataAccessMappingProfile()
   {
      Mapper.Initialize(cfg =>
      {
         cfg.CreateMap<PolicyItemDBEntity, PolicyItemDto>();
         cfg.CreateMap<PolicyTargetDBEntity, PolicyTargetDto>();
      });
   }
}

и вызвать в Startup.cs вашего микросервиса метод расширения
services.AddAutoMapper()


Вот и всё. Теперь можно объявлять конструкторы вида:
public GetApplicationRolesHandler(IMapper mapper)
{
    _mapper = mapper;
}

Метод расширения найдет профили во всех проектах решения, добавит конфигурацию из них и обеспечит биндинг IMapper на дефолтную реализацию.
Естественно в юнит-тестах IMapper можно подменить моком.

Всё вышеописанное для нативного DI .Net Core. Но при желании можно добавить и более продвинутые DI Frameworks, включая Unity.
Sign up to leave a comment.

Articles