Что может содержать DTO?

Question

[Sergey Ilichev]

Всем привет!

Недавно был дискус с коллегами по поводу того, что может содержать DTO и на сколько он должен быть чистым? Я и еще один коллега придерживаемся мнения, что DTO хоть и не должен содержать логики, но вполне может иметь метод для трансформации данных, например getFromArray. А наш тимлид, человек несомненно более опытный, говорит, что DTO должен быть максимально чистым. Почему я в этом сомневаюсь, потому что мне кажется что излишняя чистота DTO влечет слишком много гемора, что тоже не очень удобно и полезно с точки зрения поддержки кода.

Предположим, у нас приходит некий json мы его декодируем в объект или массив, потом хотим на основе него построить DTO. При этом пусть его структура будет вложенной, допустим пользователь, его профиль и массив некоторой информации дополнительной data.

{
    “guid” : “ someValue”,
    “name”: “ someValue”,
    “phoneNumber”: “ someValue”,
    …
    “userProfile”: {
        “someField”: “someValue"
    },
    “data”: {
         “someField”: “someValue"
    }
}

Хочется просто закинуть данный декодированный объект или массив в метод, dto или в его конструктор, и чтобы он сам построил всю вложенность dto. Без вызова всяких там сетов вручную. При этом вдруг мне еще надо для формирования вложенного dto скажем userProfile использовать еще и данные из уровня выше, допустим захочу телефонный номер закинуть, или мне надо закинуть его именно с плюсом спереди, или сделать любые другие преобразования с данными при построении DTO. Да, можно использовать маппер, но в чем смысл создавать еще и отдельный класс маппера? Что может пойти не так, что DTO от такой логики будет уже не DTO и какие могут быть проблемы?

Я в защиту смог только привете такой пример - до определенного момента в php вообще не было type hints и если мы делали DTO, то как правило был базовый класс, который содержал методы валидация входных данных на основе док блоков. Получается это были какие-то кривые DTO раньше?

Просто мне кажется, что все эти вот правила это на уровне рекомендаций, какие-то обоснованные, какие-то не очень. Нет, понятно что не стоит пихать в DTO бизнес логику, типа там отправку запросов, сохранение в базу данных и прочее. Но мне кажется DTO лучше быть самодостаточным в плане формирования данных, которые он будет хранить. Выглядит лучше чем мапперы с вызовами сеттеров, созданием всей этой цепочки вложенности. Или типа это уже из разряда объект формирует сам себя? А в случае с старым подходом без типов, это еще и валидация, а значит еще нарушение принципа единственной отвественности?

Кто что думает по этому поводу и как формирует DTO?

Answer 1

[index0h]

Dto - data transfer object, его задача - это передать данные. Ваш тимлид говорит верно, дто не должен содержать ничего другого кроме данных и тайпхинтинга.

Json у вас получится в какой-то точке кода, вероятно взаимодействующей с внешним миром: хттп, бд, файлы и т.д. вот именно в этой точке вам и следует делать пасинг и наполнение вашего дто

Answer 2

[Александр]

Я считаю, что может (можно сюда еще)

Логика простая - DTO не может содержать бизнес логики. DTO используется для переброски данных между слоями, сериализацияне является бизнес поведением, это просто разные способы представления плоской структуры данных. Самое главное что бы в сериализации не происходила трансформация. Это может являться частью логики. А делать отдельный класс для каждого дто для сериализации - слишком запарно.

Лично я использую сериализацию в dto.

Answer 3

[ThunderCat]

Что может пойти не так, что DTO от такой логики будет уже не DTO и какие могут быть проблемы?

DTO - чисто инструмент переноса, в классическом ООП он выполняет роль сигнала для взаимодействия между абстрактными сущностями. По этому его задача хранить данные, а логика его построения должна быть отделена. Если у вас 10 дтошек, и что-то поменялось в логике построения, вы будете все десять штук менять, что уже выглядит странно и не очень логично. Напрашивается логичное решение - использовать фэктори, которая, в противовес дто, имеет только логику, и все манипуляции с данными сводятся в 1 место. Пишете фэктори, и на каждый источник у вас свой фабричный метод, а на выходе нужный дто.

Answer 4

[Vitsliputsli]

1) Цель использования DTO - это передать данные между двумя подсистемами. Причем, либо между ними нельзя передать поведение, либо мы хотим, чтобы они были независимы, а передача поведения увеличит зацепление.
2) DTO - это специфика Java, там, объединить разнородные данные можно только в объекте. Поэтому был введен данный механизм - объект с искусственным ограничением, только данные и никакого поведения. Но, php не Java, здесь разнородные данные можно легко объединить в обычном массиве. Вы можете, конечно, массив завернуть в объект, но смысла в этом нет, т.к. мы передаем данные между независимыми подсистемами, ни одна из них не должна быть зацеплена на объекты другой.
3) Как уже написали, сам DTO и механизм его формирующий - это разные вещи, подсистемы могут вообще на разных языках быть написаны, и все будет прекрасно работать, т.к. мы передаем только данные, а не поведение. Если же хочется туда запихнуть валидацию или иное поведение, стоит задуматься, а зачем здесь DTO? Не проще ли тогда сразу передавать полноценный объект.

Comments

[Sergey Ilichev]

На счет передачи между двумя системами на разных языках, пока не встречал. То есть мы в любом случае имея объект DTO на php, не будем его передавать в сервис на go или java в таком виде, мы передадим json. Если вы об этом.

Поэтому все что внутри dto будет использоваться только внутри этого сервиса для которого создавался объект.

Я про другие языки сказать не могу, но валидация всегда была частью dto в php, по крайней мере до введения более или менее нормальной типизации свойств объекта. Сейчас да, у нас есть типизация и когда мы создаем dto мы указываем тип данных для каждого поля. А раньше как было? Раньше был базовый класс, от которого наследовались все dto, в этом базовом классе был метод, который через рефлексию парсил все данные из докблоков и на основе их делал валидацию полей. То есть это уже была логика в dto.

Плюс dto по определению вроде не должен содержать бизнес логики, при этом маппинг и сериализация не являются бизнес логикой.

До кучи еще вопрос - а что делать со вложенными дто? Вот допустим у вас есть json, в нем у вас идут вложение объекты. Вы хотите на его основе построить дто. Предлагаете вместо одного умного дто, который принимает этот json или уже массив и полностью на его основе строит готовый dto со вложенными объектами использовать отдельный маппер, где описывать простыню последовательных действий с циклами, переборами массивов, чтобы создавать вложенные дто или коллекции дто? Выглядит как-то избыточно и не очень. А какая выгода от таких действий?

Я вот хочу объект на основе массива

[
a => a,
b => [
[c => c],
[e => e],
],
f => [
[g => [h => h]],
[i => [j => j]],
],

]

И тому подобное. Если делать маппер, я должен писать там цикл перебирать эти данные, если там идет массив то перебирать и его, наполняя еще один dto на основе этих данных, так создавать коллекцию dto и потом ее присваивать первому dto как свойство. Или не едать ничего такого, а вместо вложенных dto хранить в первом в свойствах строки с json и каждый раз когда нужно преобразовывать в массив и опять маппить на другое dto.