Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Зачем нужны дата трансфер обекты и билдеры ?
Форумы портала PHP.SU » » Вопросы новичков » Зачем нужны дата трансфер обекты и билдеры ?

Страниц (1): [1]
 

1. asker - 20 Декабря, 2019 - 18:37:12 - перейти к сообщению
Привет

Вопрос основан на опыте работы с laravel где есть FormRequest для проверки дынных которые пришли из формы, но что то подобное есть и в симфони и можно вообще этот этап заменить просто проверкой в контролере на чистом php, суть вопроса не изменится.

В проекте переиодически натыкаюсь на использование билдеров и DTO для меня это выглядит очень странно потомучто вся валидация происходит в FormRequest, потом как установка данных которые пришли из реквеста в DTO а из DTO мы добавляем данные в модель и потом сохраняем те DTO(некоторый data transfer object) какойто странный промежуточный шаг. С билдерами примерно тоже самое, если я правильно понял.

Зачем тогда вообще нужны билдеры и ДТО, это не нужный лишний шаг для меня если можно напрямую данные из реквеста сохранить в модель тк они уже прошли проверку в FormRequest ?
2. LIME - 20 Декабря, 2019 - 21:10:42 - перейти к сообщению
Я не видел как это у тебя там делается, поэтому просто отвечу на вопрос из заголовка про DTO.
Зачем оно вообще надо. DTO - некий контейнер для данных. По сравнению с передачей данных в виде массива есть определенные плюсы. Можно валидировать данные в конструкторе DTO. Данные строго структурированы и типизированы. То есть в любом месте клиентского кода принимая DTO ты можешь напрямую вызывать методы ValueObject включенного в него. Без всяких isset и тому подобного набора проверок(tell don't ask). Это мы уже проверили в конструкторе. Один раз написали DTO и формируем его где нам надо. Не всегда данные приходят из формы. Возможно та же самая логика будет также запущена в каком-нибудь cron скрипте или импорте из xls файла. Во всех местах формируем один и тот же DTO, но из разных источников и разных первоначальных структур данных. И далее его передаем в тот же сервис обработки. Логика одна, а источники данных разные.
Это не все что можно сказать по теме.
Вот для ознакомления - https://www[dot]youtube[dot]com/watch?v=rjtbCyacJas (не воспринимать буквально как библию, это только для ознакомления)
И на закуску про ассерты(в конструкторе DTO удобно) вот это например https://www[dot]youtube[dot]com/watch?v=8v02-XPm3Do
(Добавление)
А вообще подобными вопросами частенько задаются думающие новички. На простых проектах что-то кажется лишним. Более сложные проекты требуют большей гибкости. Но ничего не дается бесплатно. Платим сложностью кода.
3. Vaganec Trosti - 09 Января, 2020 - 09:01:49 - перейти к сообщению
Этими dto-шками в слоистых архитектурах переходят границы.
Поищите про чистые архитектуры, гексогональные, луковые.
4. LIME - 09 Января, 2020 - 09:48:42 - перейти к сообщению
Dto не имеет отношения к слоеной архитектуре. И к гексагональной тоже. Это вообще не про архитектуру, а про структурированность и типизацию.
5. LIME - 11 Января, 2020 - 14:54:10 - перейти к сообщению
Vaganec Trosti пишет:
переходят границы.
передавая скаляры и массивы мы вынуждены проверять данные в каждой точке приема
DTO переносит проверки в одну точку - формирование DTO
+ можем сразу юзать методы объектов входящих в DTO без instanceof
как это может переходить границы я не понимаю

 

Powered by ExBB FM 1.0 RC1