IT заметки по программированию
IT заметки по программированию
IT заметки по программированию
IT заметки по программированию

DTO — простой (плоский) объект? У него могут быть методы?

16.03.2022
Golang, Архитектура
Комментариев нет

DTO (Data Transfer Object) действительно по своей сути является простым и плоским объектом, предназначенным для передачи данных между слоями приложения. Его основная цель — перенос данных, а не реализация поведения или бизнес-логики. Однако в практике программирования DTO может включать методы, если они соответствуют следующим условиям:

1. Методы для преобразования

Часто в DTO добавляют вспомогательные методы для преобразования в другую структуру, например, в Entity. Это не нарушает принцип «простоты», так как такие методы относятся исключительно к удобству использования объекта для передачи данных.

Пример:

Go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
type UserDTO struct {
    ID    string `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}
 
type UserEntity struct {
    ID       string
    FullName string
    Email    string
}
 
// Метод для преобразования DTO в Entity
func (dto UserDTO) ToEntity() UserEntity {
    return UserEntity{
        ID:       dto.ID,
        FullName: dto.Name,
        Email:    dto.Email,
    }
}
 
Почему это допустимо?

  • Такие методы не добавляют поведения к DTO, а только служат для удобства преобразования.

2. Методы для валидации

В редких случаях можно добавить методы, которые помогают проверить корректность данных, содержащихся в DTO. Однако лучше проводить валидацию вне DTO, чтобы сохранять его как можно более «плоским».

Пример:

Go
1
2
3
4
5
6
7
8
9
10
func (dto UserDTO) Validate() error {
    if dto.Name == "" {
        return fmt.Errorf("имя пользователя не может быть пустым")
    }
    if dto.Email == "" {
        return fmt.Errorf("email не может быть пустым")
    }
    return nil
}
 
Почему это допустимо?

  • Если валидация относится исключительно к данным внутри DTO, то её можно считать частью ответственности самого объекта.
  • Но если валидация требует сложной логики (например, проверки уникальности email в базе), лучше вынести её в отдельный слой (например, сервис).

3. Методы для сериализации/десериализации

Иногда можно добавить методы для удобства сериализации или десериализации данных в формат JSON, XML и т.д., хотя стандартные библиотеки Go обычно справляются с этим автоматически.

Пример:

Go
1
2
3
4
5
6
7
8
func (dto UserDTO) ToJSON() (string, error) {
    data, err := json.Marshal(dto)
    if err != nil {
        return "", err
    }
    return string(data), nil
}
 

4. Методы, которых лучше избегать

DTO не должен содержать:

  • Методы, которые изменяют внутреннее состояние объекта (мутация данных).
  • Методы, связанные с бизнес-логикой или процессами приложения (например, вычисления, сохранение в базу данных и т.д.).
  • Сложные методы, которые нарушают принцип разделения ответственности.

5. Почему вообще добавляют методы в DTO?

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

  • Для удобства: чтобы избежать дублирования кода при преобразовании данных.
  • Для самодостаточности: чтобы объект мог «знать», как преобразовать себя в другую форму или проверить свою корректность.

6. Как поддерживать «чистоту» DTO?

Если вы хотите придерживаться строгой интерпретации DTO как простого объекта, сделайте следующее:

  • Вынесите все методы преобразования и валидации в отдельные пакеты или слои (например, в мапперы, валидаторы).
  • Оставьте DTO только с полями и стандартными тегами (например, json для сериализации).

Пример использования маппера:

Go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
type UserMapper struct{}
 
func (m UserMapper) ToEntity(dto UserDTO) UserEntity {
    return UserEntity{
        ID:       dto.ID,
        FullName: dto.Name,
        Email:    dto.Email,
    }
}
 
// Использование
mapper := UserMapper{}
entity := mapper.ToEntity(dto)
 

Заключение

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

Recommended Posts

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *