Ну вот мы пишем вот так

Правила валидации внутри DTO

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

Второй пример ровно 1 строка))

Открываете статьи что такое дто и смотрите

Если я напишу такую статью и скажу, что можно будет считаться ? Окей, даю отсылку на https://www.ozon.ru/product/robert-martin-rekomenduet-kod-kotoryy-umeshchaetsya-v-golove-evristiki-dlya-razrabotchikov-981458526/ Симан Марк пишет как раз про Parse внутри DTO

нет из данных в dto, анпример UserDTO, создать объект User через метод Parse

FromRequest это ваша реализация Argument Resolver? Или что-то встроенное?

все верно

Причем здесь мое личное отношение?

Если я напишу такую статью и скажу, что можно будет считаться ? Окей, даю отсылку на https://www.ozon.ru/product/robert-martin-rekomenduet-kod-kotoryy-umeshchaetsya-v-golove-evristiki-dlya-razrabotchikov-981458526/ Симан Марк пишет как раз про Parse внутри DTO

Привел пример из книги достаточно известного в мире java программиста с большим опытом работы

Так же этот вопрос про DTO буквально недавно задавал в большой группе телеграмма, где парни с большим опытом. Не знаю можно или нет давать ссылку, скорее всего вы о ней знаете

Привет всем! Уверен такой вопрос уже поднимался ни одну тысячу раз. Допускается ли в DTO: - Валидация внутри - Установка дефолтных значений - Методы возвращающие готовые объекты из данных, как пример RequestUserDTO->Parse() // User

Привел пример из книги достаточно известного в мире java программиста с большим опытом работы

а почему нет? ну то есть важен контекст почему и на что влияет это все. Но в общем и целом единственное ограничение - "dto тупая структурка которую можно сериализовать и передавать между слоями". Что может быть как часть этой структурки это уже не важно, и надо смотреть просто по зависимостям кто с каком стороны дергает и кому можно это дергать

` Методы возвращающие готовые объекты из данных, как пример RequestUserDTO->Parse() // User` Врядли Протько вчитался в вот это, потому что его ответ не содеожит на это ответ

Тупая структура = без логики

Слушай я думаю в твоём примере это было бы как $editDTO->createEditCommand(); Как итог - твоя команда ничего не знает про валидацию и реквест.

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

Нет. Вы ошибаетесь. Тупая структура != без логики в этом случае. DTO должно соответствовать тупой структуре, например в момент передачи. То есть то что от нее ожидают, то и делать.

Нет. Вы ошибаетесь. Тупая структура != без логики в этом случае. DTO должно соответствовать тупой структуре, например в момент передачи. То есть то что от нее ожидают, то и делать.

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

дело не только в слоях Допустим данные приходят как {email: "test@mail.com", age: 21, name: "Вася"} а перобразовать нужно в сущность new Command(email: new Email("test@mail.com"), age: new Age(21), name: "Вася") Думаю врядли твой умный маппер такое сможет

Нет, valueObject норм собираются

Я привел пример книги, где эту структуру расширили. Статьи тоже люди пишут. Нет единного фолианта и у меня не спор ради спора. Пришел человек с идей расширения DTO, я и сказал, что так делать можно

Нет, valueObject норм собираются

Ну то есть у тебя всё тоже самое, просто в моём примере это было без лишней магии

Ну то есть у тебя всё тоже самое, просто в моём примере это было без лишней магии

public function search(?string $status, ?string $created_at, ?string $updated_at) { $query = $this->createQueryBuilder('stmt'); if ($status) { $query = $query->where('status', $status); } if ($created_at) { $query = $query->where('created_at', 'like', $created_at.'%'); } if ($updated_at) { $query = $query->where('updated_at', 'like', $updated_at.'%'); } return $query->getQuery()->getResult(); } в symfony вручную надо выбирать where или AndWhere?

а есть может библиотека чтоб загрузить модель автоматически, как в ларе?

public function search(?string $status, ?string $created_at, ?string $updated_at) { $query = $this->createQueryBuilder('stmt'); if ($status) { $query = $query->where('status', $status); } if ($created_at) { $query = $query->where('created_at', 'like', $created_at.'%'); } if ($updated_at) { $query = $query->where('updated_at', 'like', $updated_at.'%'); } return $query->getQuery()->getResult(); } в symfony вручную надо выбирать where или AndWhere?

В простом случае да, только лучше передавать или массив или дто в такой метод, а не 1 критерий, 1 аттрибут

Ну если автомаппер назвать магией, то да. Опять же ваш editDto собирается такой же магией, и в чем разница?

там не просто маппер же, ты когда команду делаешь у тебя и валидация может происходить

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

просто везде andWhere указывай и не парься

"detail": "[Syntax Error] line 0, col 51: Error: Expected =, <, <=, <>, >, >=, !=, got 'AND'", "class": "Doctrine\\ORM\\Query\\QueryException",

Как дто сделает сущность, если сущности нужна другая сущность?

я не помню как в книге, давненько ее читал, но там весь основной прикол Parse был в поддержке IDE и проерках. Что у тебя различного рода валидации проходят не в коде создания User, а внутри DTO и когда ты из DTO будешь получать User он уже будет валиден