В слоёных приложения данные на разных уровнях зачастую представлены в виде разных объектов. Например во время получения данных из БД при помощи EF выполняются манипуляции используя доменные объекты. Возможно там же результат будет оформлен в виде DTO или модели команды уровня бизнес-логики. Далее на уровне WEB API эти данные будут преобразованы в ответ сервера (Response). Такое поведение оправдано и служит для разделения ответственности. Однако печаль-беда в том, что зачастую данные между моделями разных уровней передаются при помощи копирования. Иногда вручную, иногда используя AutoMapper, Mapster или Mapperly, для удобства. Инструменты безусловно шикарные, однако сам подход copy\paste, как известно, не лишён недостатков. Возможно имеется альтернативное решение? Конечно, и не одно.

В самом простейшем случае можно прибегнуть к помощи полиморфизма, т.е. чтобы сценарий использования (UseCase, Command pattern) в качестве параметров принимал не конкретную модель, а абстракцию:

/// <summary> Модель запроса к WEB API и модель аргументов команды одновременно/summary>
public sealed record CreateTodoListRequest(string Title) : ICreateTodoListCommandArgs;

/// <summary> Абстракция аргументов команды "Создать список дел"</summary>
public interface ICreateTodoListCommandArgs
{
    string Title { get; }
}

/// <summary> Ообработчик команды </summary>
public class CreateTodoListCommandHandler : IHandler<ICreateTodoListCommandArgs, int>
{
  public Task<int> Handle(ICreateTodoListCommandArgs request, CancellationToken cancellationToken)
  {
  }
}

Однако у этого подхода есть недостатки.Во первых с популярной нынче библиотекой MediatR он не работает. Всё потому, что поиск обработчика осуществляется на основании экземпляра запроса. Не хотелось бы в это углубляться, так что если есть желание, можете «помедитировать» над кодом request.GetType() метода Send класса Mediator.

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

/// <summary> Абстракция обработчика</summary>
public interface IHandler<in TArgs, in TResultAbstraction>
{
    Task<TResult> Handle<TResult>(TArgs args, CancellationToken cancellationToken)
        where TResult : TResultAbstraction, new();
}

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

public interface IGetTodosQueryHandler
{
    Task<TResult> Handle<TResult, TPriorityLevelItem, TListItem, TTodoItem>(CancellationToken cancellationToken)
        where TResult : IGetTodosQueryResult<TPriorityLevelItem, TListItem, TTodoItem>, new()
        where TPriorityLevelItem : ILookup, new()
        where TListItem : ITodoList<TTodoItem>, new()
        where TTodoItem : ITodoItem, new();
}

А такая реализация, согласитесь, уже не выглядит адекватной.

Хорошо, раз с интерфейсами не сложилось, тогда можно применить другой подход — агрегацию:

/// <summary>Domain Entity </summary>
public sealed class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; } = null!;
    // ...
}

/// <summary>WEB Response создаваемый путём агрегации</summary>
/// <param name="person">источник данных</param>
public sealed class PersonResponseWrapper(Person person)
{
    public int Id => person.Id;
    public string FirstName => person.FirstName;
    // ...
}

Да-да, вы всё правильно поняли — приёмник данных реализован в виде обёртки над источником. Таким образом для каждого слоя будет своя модель, но без копирования. В конечном счёте это должно немного уменьшить потребление памяти, а возможно и быстродействие…
В теории, а что там на практике?

Экспериментировать буду вот на такой модели:

/// <summary>Domain Entity </summary>
public sealed class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; } = null!;
    public string LastName { get; set; } = null!;
    public DateOnly? Birthdate { get; set; }
    public bool? Gender { get; set; } // 0 = Female, 1 = Male
    public string Email { get; set; } = null!;
    public int Score { get; set; }
}

Исходники на GitHub.

Для начала посмотрим насколько отличается копирование от «обёртывания»:

Примерно в 2 раза по скорости и в 2,5 раза по памяти.
Любопытная картина, если создать обёртку в виде структуры — это практически ничего не стОит. Однако скорее всего, в процессе передачи в другие методы такая обёртка будет упакована в объект (Boxing), что приведёт к затратам сравнимым с использованием объекта.

Хорошо, теперь сравним преобразование множества объектов — исходную коллекцию можно преобразовать в список (List), массив (Array) и перечислимое (IEnumerable). Источник содержит 25 элементов:

Занимательно не так ли?
Использование структуры в качестве обёртки в сочетании с использованием перечислимого примерно в 6,5 раз быстрее и в 40 раз эффективнее по памяти. Для 100 элементов превосходство по памяти уже в 153 раза. Вот она — сила перечислимого!
И ещё массивы всегда чуть-чуть лучше списков по ресурсам. Совсем чуть-чуть, но лучше. Поэтому если не планируется добавлять элементы, то ToArray предпочтительнее ToList.

Ладно теперь добавим немного реализма — будем сериализовать множество при помощи System.Text.Json.JsonSerializer. Это как раз то, чем будет заниматься WEB API:

Хоба! Тут цифры совсем не такие внушительные. Причём частенько бывало так, что массив или список отрабатывали даже на 1-2% быстрее перечислимого. Но по памяти использование обёртки и перечислимого всегда давало лучший результат. С увеличением объёма данных отрыв также увеличивался.

Наверняка найдутся и те, кто скажет «да тут выигрыш в производительности на уровне погрешности, и памяти на 1 килобайт в 0-м поколении — оно того не стоит». Да, согласен, выигрыш небольшой, но он есть и достаётся нам совершенно бесплатно, потому что ни трудозатраты, ни сложность кода не увеличиваются.

А кстати, что там по части сторонних Mapper’ов? Они то как раз немного сокращают трудозатраты. Что ж — давайте посмотрим:

Ну да, ну да — за комфорт нужно платить :-)