Перейти на PRO

Какие проблемы решает использование DTO (Data Transfer Object)?

Тип вопроса: Архитектура Вероятность: 24% Категория: PHP Разработчик

Ответ

В моей практике DTO — это простые объекты, предназначенные исключительно для передачи данных между слоями приложения или между сервисами. Они решают несколько ключевых проблем:

  1. Изоляция доменной модели от слоя представления/API: DTO предотвращает «просачивание» логики домена или внутренней структуры сущностей во внешние контракты (например, REST API). Это защищает домен от изменений, требуемых внешними потребителями.

    • Без DTO: API напрямую возвращает сущность User с полями passwordHash, createdAt, которые клиенту не нужны.
    • С DTO: API возвращает UserResponseDto, содержащий только id, email, name.

  2. Снижение связности между слоями: Контроллеры или внешние клиенты зависят от стабильного контракта DTO, а не от изменчивой внутренней доменной модели.

  3. Оптимизация сетевых запросов: DTO позволяют формировать ответ, содержащий именно те данные, которые нужны клиенту, объединяя информацию из нескольких сущностей (например, заказ + данные клиента), избегая проблемы over-fetching или under-fetching.

  4. Стандартизация и валидация входящих данных: DTO на входе API — это удобное место для аннотаций валидации.

Пример на C#:

// Внутренняя доменная сущность
public class User {
    public int Id { get; private set; }
    public string Email { get; private set; }
    public string PasswordHash { get; private set; }
    public DateTime CreatedAt { get; private set; }
    // Доменные методы...
}

// DTO для ответа API
public record UserResponseDto(int Id, string Email, string FullName);

// DTO для запроса на создание пользователя с валидацией
public record CreateUserRequestDto {
    [Required, EmailAddress]
    public string Email { get; init; }

    [Required, MinLength(6)]
    public string Password { get; init; }

    [Required]
    public string FullName { get; init; }
}

// В контроллере
[HttpPost]
public IActionResult CreateUser([FromBody] CreateUserRequestDto request) {
    // Автоматическая валидация DTO сработает до этого места
    var user = _userService.CreateUser(request.Email, request.Password, request.FullName);
    var response = new UserResponseDto(user.Id, user.Email, user.FullName);
    return Ok(response);
}

Основной компромисс — это необходимость написания маппинга (например, с помощью AutoMapper) между доменными объектами и DTO, что добавляет шаблонного кода.

Ответ 18+ 🔞

А, DTO, ёпта! Ну, классика же, как два пальца обоссать. Представь, что твоя доменная сущность — это такой мощный, накачанный чувак в спортзале, со всеми его секретными методиками и баночками протеина. А DTO — это его парадный костюм на выход в свет. Ты же не пойдёшь в ресторан в потной майке, с криком «я жму сто пятьдесят», верно? Вот и здесь так же.

Зачем эта мартышлюшка вообще нужна?

  1. Чтоб не светить лишнее. Это, блядь, основа основ. Твоя доменная сущность User знает про passwordHash и createdAt. А зачем это клиенту? Ему от этого только волнение ебать. DTO (UserResponseDto) даёт ему только id, email и name — чётко, сухо, без подноготной. Это как не пускать соседа в свой холодильник, показывая только начищенную кухню.

  2. Чтоб не зависеть от изменений. Если твой внутренний «качок» (User) решит сменить методику тренировок (поменять структуру), то его парадный костюм (DTO) для внешнего мира может остаться прежним. Клиенты даже не узнают, что у тебя там теперь HashedPassword вместо PasswordHash. Связность — ноль ебать.

  3. Чтоб не тащить овердохуища данных. Клиенту нужен заказ и имя того, кто его сделал. Без DTO пришлось бы тащить всю хуйню связанных сущностей, а это долго и жирно. DTO позволяет собрать в одну аккуратную коробку (OrderWithClientDto) только то, что просили. Ни больше, ни меньше. Оптимизация, мать её.

  4. Чтоб отсеивать шлак на входе. Косячный запрос от клиента? DTO на входе (CreateUserRequestDto) с аннотациями валидации — это как швейцар в клубе. «Извините, сэр, ваш email не соответствует дресс-коду, и password слишком короткий. До свидания». Всё отвалится ещё до того, как запрос доберётся до твоей бизнес-логики.

Ну и пример, чтоб совсем понятно было:

// Это твой внутренний чувак, со всеми его тараканами.
public class User {
    public int Id { get; private set; }
    public string Email { get; private set; }
    public string PasswordHash { get; private set; } // Это клиенту не показываем! Сам от себя охуеет.
    public DateTime CreatedAt { get; private set; }
    // ... куча доменной логики ...
}

// А это его официальная фотка для инстаграма. Только лучшее.
public record UserResponseDto(int Id, string Email, string FullName);

// А это анкета, которую он заполняет, чтобы попасть в клуб. С проверками.
public record CreateUserRequestDto {
    [Required, EmailAddress]
    public string Email { get; init; }

    [Required, MinLength(6)]
    public string Password { get; init; }

    [Required]
    public string FullName { get; init; }
}

// И как это всё работает в контроллере
[HttpPost]
public IActionResult CreateUser([FromBody] CreateUserRequestDto request) {
    // Сюда приходит уже проверенный запрос. Доверия ебать ноль, но валидация сработала.
    var user = _userService.CreateUser(request.Email, request.Password, request.FullName);
    // Маппим внутреннего монстра в приличный ответ.
    var response = new UserResponseDto(user.Id, user.Email, user.FullName);
    return Ok(response);
}

А компромисс где? Да вся эта ебля с маппингом! Писать эти конвертеры из User в UserResponseDto — шаблонный код овердохуища. Приходится юзать AutoMapper или вручную писать, что, в общем-то, иногда превращается в пиздопроебибну. Но игра стоит свеч, когда не хочешь, чтобы твой внутренний мир полетел к чёрту из-за чужого кривого запроса.

Видео-ответы

© ХакСобесов, 2026
support@hacksobesov.com