Блеск и нищета мапперов объектов в .net

Всем привет, меня зовут Сергей, я системный архитектор в компании Bimeister, и, как вы уже догадались, сегодня мы поговорим про маппинг объектов в .net.

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

Статья ориентирована на младших разработчиков, которые впервые сталкиваются с темой маппинга объектов и на всех неравнодушных. В данной статье мы не будем касаться широкой темы разнообразных ОRМ-ов (Object­Relational Mapping), а также темы сериализации/десериализации данных, которую тоже часто называют маппингом. Мы рассмотрим сопоставление объектов между различными слоями нашего приложения, например DТО (Data Transfer Object) и объектом из базы данных, с которым оперирует Entity Framework.

Итак, начнём!

Начнем со всем известных понятий...

Уровень данных (Data Layer) — предоставляет источники данных остальной части приложения, содержит локальные и удаленные источники данных, мапперы и репозитории.

Уровень домена (Domain Layer) — содержит бизнес-логику, оперирует кейсами и моделями предметной области и репозитории.

Уровень представления (Presentation Lауег) — содержит действия, фрагменты модели представлений и адаптеры.

Зачем это нужно?

С увеличением кодовой базы проекта мы, как правило, задумываемся о выстраивании удобной для разработки и поддержки кода архитектуры... и приходим к проблеме маппинга объектов с одного слоя на другой.

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

У нас несколько классов, которые представляют собой сущности уровней данных и представления:

public class ClientDto
{
    public long Id { get; set; }
    public string Email { get; set; }
    public string? FullName { get; set; }
}

public class EntityObject
{
    public Guid Id { get; set; }
    public string Type { get; set; }
    public string Name { get; set; }
    public string? Description { get; set; }
    public long ClientId { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime UpdateDate { get; set; }
}

public class EntityDto
{
    public Guid Id { get; set; }
    public string Type { get; set; }
    public string Name { get; set; }
    public string? Description { get; set; }
    public DateTimeOffset StartDate { get; set; }
    public DateTimeOffset UpdateDate { get; set; }
    public ClientDto Client { get; set; }
}

Давайте же посмотрим, какие есть способы смаппить объекты.

Способ №1. Ручной маппинг объектов.

Никаких пререквизитов нет. Самый простой способ сделать это — создать инстанс объекта вручную в том месте, где вам нужен целевой объект:

EntityObject sourceObject = await _someService.GetObjectAsync();
EntityDto dest = new()
  {
      Id = sourceObject.Id,
      Type = sourceObject.Type,
      Name = sourceObject.Name,
      Description = sourceObject.Description,
      StartDate = sourceObject.StartDate,
      UpdateDate = sourceObject.UpdateDate,
      Client = new ClientDto
      {
          Id = sourceObject.ClientId
      }
  };

Для того чтобы снизить дублирование, можно вынести эту часть в отдельный метод или сделать extension:

public static class MappingExtensions
{
    public static EntityDto MapToDto(this EntityObject? mappingObject)
    {
        if (mappingObject == null)
            throw new ArgumentNullException(nameof(mappingObject));
        EntityDto dest = new()
        {
            Id = mappingObject.Id,
            Type = mappingObject.Type,
            Name = mappingObject.Name,
            Description = mappingObject.Description,
            StartDate = mappingObject.StartDate,
            UpdateDate = mappingObject.UpdateDate,
            Client = new ClientDto
            {
                Id = mappingObject.ClientId
            }
        };

        return dest;
    }
}

Плюсы:

• вы сами управляете всем и можете реализовать любой по сложности маппинг;

• не нужны дополнительные зависимости и их конфигурация.

Минусы:

• вам приходится самим управлять своим маппингом, даже в простых конфигурациях;

• в некоторых случаях не получится полностью избежать дублирования инфраструктурного кода.

Способ №2. С использованием AutoMapper

Нам нужен NuGet-пакет, для использования в ASP.NET проще всего использовать этот:

dotnet add package AutoMapper.Extensions.Microsoft.DependencyInjection

Чтобы зарегистрировать mapper и конфигурацию в DI, достаточно добавить в ConfigureServices следующую строчку:

services.AddAutoMapper(assembly1, assembly2 /*, ...*/);
// or 
services.AddAutoMapper(type1, type2 /*, ...*/);

Это зарегистрирует конфигурацию MapperConfiguration как Singleton и реализацию IMapper как transient, а также добавит дополнительно различные converters, resolvers и т.д.

И, собственно, сам маппинг:

EntityObject sourceObject = await _someService.GetObjectAsync();
// IMapper mapper достается из DI
mapper.Map<EntityDto>(_sourceObject);
// Также есть non-generic версия этого метода, 
// когда вы не знаете какой у вас тип во время компиляции

Для простых сценариев это подойдет, но если вы хотите управлять маппингом, есть возможность настроить профиль:

public class MappingProfile : Profile
{
    public MappingProfile()
    {
        CreateMap<EntityObject, EntityDto>()
            .ForMember(dest => dest.Id, o => o.MapFrom(src => src.Id))
            .ForMember(dest => dest.Type, o => o.MapFrom(src => src.Type))
            .ForMember(dest => dest.Name, o => o.MapFrom(src => src.Name))
            .ForMember(dest => dest.Description, o => o.MapFrom(src => src.Description))
            .ForMember(dest => dest.StartDate, o => o.MapFrom(src => src.StartDate))
            .ForMember(dest => dest.UpdateDate, o => o.MapFrom(src => src.UpdateDate))
            .ForMember(dest => dest.Client, o => o.MapFrom(src => new ClientDto {Id = src.ClientId}));
    }
}

Когда нам нужна гибкость и мы хотим взять под контроль преобразование одного типа в другой, можно использовать механизм TypeConverters:

public class DateTimeTypeConverter : ITypeConverter<string, DateTime>
{
    public DateTime Convert(string source, DateTime destination, ResolutionContext context)
    {
        return System.Convert.ToDateTime(source);
    }
}

И использовать его в профиле:

.ForMember(dest => dest.UpdateDate, o => o.ConvertUsing<DateTimeTypeConverter>(src => src.UpdateDate));

Для работы с вычисляемыми значениями есть IValueResolver и IMemberValueResolver.

Automapper имеет также много дополнительных настроек в виде управления NamingConventions, замены символов в членах класса, определения prefix/postfix при маппинге членов класса, фильтрации полей, включения компиляцию конфигураций маппингов (по умолчанию компиляция ленивая) и т.д.

Плюсы:

• сокращается большое количество инфраструктурного кода;

• не нужны дополнительные зависимости и их конфигурация.

Минусы:

• механизм с профилями сложен в поддержке, так как сложно понять, какие профили используются;

• появляются дополнительные зависимости в проектах, нужно актуализировать список assembly, в котором лежат профили, чтобы исключить ошибки при маппинге;

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

AutoMapper хорошо использовать в небольших проектах или в ситуации когда профили меняются редко и когда мы не "выжимаем" максимум возможностей гонясь за каждыми миллисекундами.

Информация о библиотеке:

• Исходный код: Github

• Документация: Docs

• Популярность: Stars 9K/Forks 1.7K, постоянные релизы раз в пару месяцев

• Последний релиз: октябрь 2022

• Количество загрузок в nuget: 300 миллионов

Способ 3. С использованием Mapster

Для работы с библиотекой нам также нужен дополнительный NuGet-пакет:

dotnet add package Mapster.DependencyInjection

Добавляем в DI через ConfigureServices и конфигуриуем:

...
services.AddSingleton(TypeAdapterConfig.GlobalSettings);
services.AddScoped<IMapper, ServiceMapper>();
...

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

EntityObject sourceObject = await _someService.GetObjectAsync();
// маппинг в новый объект
EntityDto destObject = sourceObject.AdaptTo<EntityDto>();
// или в существующий объект
sourceObject.AdaptTo<EntityDto>(destObject);

Настройка маппинга осуществляется через TypeAdapterConfig:

public class MappingConfig : TypeAdapterConfig
{
    public MappingConfig()
    {
        ForType<EntityObject, EntityDto>()
            .Map(dest => dest.Id, src => src.Id)
            .Map(dest => dest.Name, src => src.Name);
    }
}

Библиотека может почти все то же, что и AutoMapper, касательно Naming Conventions и Custom Converters.

Mapster — также гибко настраиваемый, умеет маппинг private-членов класса, условный и с нескольких источников.

Дополнительно хочу отметить возможность маппить отдельные свойства и null propagation:

TypeAdapterConfig<EntityObject, EntityDto>.NewConfig()
    .Map(dest => dest.Client.Id, src => src.ClientId);

TypeAdapterConfig<EntityDto, EntityObject>.NewConfig()
    .Map(dest => dest.ClientId, src => src.Client.Id);

Кодогенерация предполагает, что Mapster сам сможет сформировать целевой DTO и реализовать маппинги для него. Для ее работы нужен пакет Mapster.Tools:

dotnet add package Mapster.Tools

И интерфейс для маппера:

[Mapper]
public interface IEntityObjectMapper
{
    EntityDto MapTo(EntityObject student);
}

Вот и все, в результате сборки мы получим сгенерированный файл *.g.cs, в котором будет реализован маппинг. Такие файлы я рекомендую исключить из репозитория, это позволит избежать проблем при совместной работе, например, когда кто-то из разработчиков менял свойства исходного объекта и не пересобрал проект.

Плюсы:

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

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

Минусы:

• Варианты с кодогенерацией не совсем привычны, особенно если использовал раньше AutoMapper.

• Меньше возможностей кастомизации — я не нашел аналогов IMemberValueResolver.

Mapster был разработан, чтобы быть эффективным решением по скорости и памяти, если вы пишите высокопроизводительный продукт — этот маппер окажется хорошим выбором.

Информация о библиотеке:

• Исходный код: Github

• Документация: Docs

• Популярность: Stars 3K/Forks 237, релизы несколько раз в год

• Последний релиз: Февраль 2022

• Количество загрузок в nuget: 8 миллионов

Производительность

Тесты выполнялись с помощью BenchmarkDotNet.
Первая колонка говорит нам про название теста, я протестировал простой маппинг и маппинг коллекций различных размеров. Все примеры можно увидеть по ссылке на Github. Остальные колонки: среднее значение работы теста, ошибка, стандартное отклонение и медиана. Вся техническая информация о запуске и результаты приведены в таблице:

BenchmarkDotNet=v0.13.2, OS=Windows 10 (10.0.19044.2006/21H2/November2021Update)
Intel Core i5-10210U CPU 1.60GHz, 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.305
  [Host]     : .NET 6.0.10 (6.0.1022.47605), X64 RyuJIT AVX2
  Job-MNIIYB : .NET 6.0.10 (6.0.1022.47605), X64 RyuJIT AVX2
Runtime=.NET 6.0  RunStrategy=Throughput  

Вместо выводов:

Я рассмотрел лишь самые популярные варианты. Были еще интересные кандидаты, но я не стал их рассматривать по причине или редких релизов или очень давней последней версии, но это не повод вовсе не упомянуть их (ExpressMapper и его форк для net standard, а также TinyMapper).

Также есть интересное решение, позволяющее генерировать маппинг через расширение среды разработки Visual Studio - Mapping Generator, но за некоторые возможности придется заплатить.

Все выводы я рекомендую делать вам самим, потому что, как бы нам не хотелось, «серебряной пули» не существует, нужно выбирать решение, которое подходит вам, исходя из ваших задач, размера проекта, команды разработки и принятых практик.
И все-таки, автоматический маппинг — полезная и удобная вещь, которая в больших проектах позволяет снизить количество boilerplate-кода и снизить архитектуру в чистоте.

Ссылка на исходные тексты примеров и тестов