Я к тому что к примеру, у тебя в дто стоит не нулабл поле, в реквесте нуль прилетает

Че дальше?

Или в дто всё нулабл?

Я к тому что к примеру, у тебя в дто стоит не нулабл поле, в реквесте нуль прилетает

конструктор/валидатор не пропустил создание такой дто

Или ты руками риквест мапиш в ДТО и проверяешь на нул?

И че

Вместо ошибки валидации 500 ошибка потому что конструктор не пропустил?

так есть же валидатор

условный #[NotBlank] на поле

Валидатор работает с готовым дто

Как ты сделаешь готовый дто?

Как смапить нул в не нулабл поле?

Или в дто всё нулабл?

нет. смотря как собираешь дто

Ну а как его надо собирать?

ну если говорим про реквест с джосна с помощью серализера

Просто с этими тайпд пропертчми валидатор к херам сломан теперь

а серализер уже собирет все ошибки

https://symfony.com/doc/current/components/serializer.html#collecting-type-errors-while-denormalizing

Т.е. валидация нула теперь на валидаторе?

нет)

Ой на сериализаторе

дыа,так как связано с типизацией

И это надо его ошибку еще конвертировать в формат ошибок который фронту понятен

ну уже все из коробки есть

Он возвращает constraints violation list?

так в примере собирается же

Вижу да

Понял

Ладно всеравно непонятно. Почему нельзя проверять валидность энтити в валидаторе

Потому что entity по нормальному не должна валидироваться никогда через валидатор

Я просто дед и вылез из симфы когда там еще все вадидировали энтити

Во всех доках так было

Видимо с того времени непонимание что в этом плохого

И формы мапились напрямую в энтити

Как-то все работало

Да и сейчас на сайте симфы примеры кода валидатора с валидацией энтити

Это все видимо корни растут от того что каждый понимает под энтити. Для кого-то это просто метаданные для БД. Для других это бизнес объект

Если рассматривать энтити как метаданные, то согласен, нужна прослойка перед ними

Это все видимо корни растут от того что каждый понимает под энтити. Для кого-то это просто метаданные для БД. Для других это бизнес объект

Если посмотреть, в документации много где "best" practice описаны

Ну я бы тогда не брал вообще доктрину

Ну я бы тогда не брал вообще доктрину

Почему

Потому что это оверкил

Если вся логика и по сути отношения описаны в ДТО

Дублирование какое-то

Потому что это оверкил

Если не использовать некоторые костыли, то нормально

Если вся логика и по сути отношения описаны в ДТО

Какая логика в ДТО?

А где логика?

А где логика?

В сущностях

Допустим логика что полное имя это фамилия плюс имя

Ну я бы тогда не брал вообще доктрину

в этом есть определенный смысл, ну точнее выкинуть doctrine/orm. dbal вполне себе можно оставить с поправкой на то, что оно когда-нибудь научится в апсерты

но замучаешься процессить ассоциации, это прям реально будет болью

Допустим логика что полное имя это фамилия плюс имя

ДТО обычно валидируется на простые кейсы (длина, кол-во и тд, что-то посложнее в сущностях)

кстати, а ты знаешь, что в доктрине (орме) можно селектить прям в дто?

https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/dql-doctrine-query-language.html#new-operator-syntax

Я не знаю ибо мне никогда дто не нужен был )

https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/dql-doctrine-query-language.html#new-operator-syntax

😳 ничосе

Очень удобная фича, между прочим)

Регулярно юзаю, когда надо куски данных отдать

Регулярно юзаю, когда надо куски данных отдать

Валидируешь перед отдачей? )

Валидируешь перед отдачей? )

Как правило нет. А собственно зачем?

дед троллит!

А, Сорян. Не выкупил(

Видимо с того времени непонимание что в этом плохого

Дело не в том, что это прям плохо, дело просто в подходе. Инкапсулирование логики в сущности дает некую защиту. С другой стороны, много сущностей почти без собственной логики и обычные круды. Например брать апи платформу, она вообще десериализует реквест сразу на энтити,без форм. Там же и валидирует, и сериалайз делает, и акссес лаер - все в сущности. И в принципе, это очень удобно и быстро там где почти нет логики. Но где логика - придаст боли и проблем. Некоторые вообще используют паралельно несколько методов, плюс вообще транзакшн скрипт, и это неплохо. Короче вопрос неоднозначный. Просто хорошо знать плюсы, минусы и варианты.

Согласен. ДТО маст хев если много мест в коде где нужно создавать энтити в разных условиях

А если единственное место где она создаётся это метод контроллера то там мне кажется и без дто можно

А то получается какой-то RTO

Request transfer object

Хотя я заметил что в компилируемых языках намного чаще если не почти всегда используется dto, поэтому может это просто хороший способ писать как надо

Согласен. ДТО маст хев если много мест в коде где нужно создавать энтити в разных условиях

Ну дтохи могут быть и не для создания.

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

Вообще это дто можно сказать немного недоделанный паттерн команда

Вообще это дто можно сказать немного недоделанный паттерн команда

Ну не, это стандарт рефакторинга, что когда много параметров у метода, то сделать объект

дто - это паттерн "структура", не больше и не меньше. это просто способ добавить типизации ассоциативным массивам

Если развить идею ДТО то в итоге прийдёшь к команде

не надо усложнять, это вообще не про проектирование, это просто способ упорядочить данные

не надо усложнять, это вообще не про проектирование, это просто способ упорядочить данные

Ну еще есть тема про разделение слоев

Но не стоит усложнять

Просто видимо в чем трабла

Мне кажется что дто это какая-то полумера

Что-то такое посередине