Вложенные DTO Symfony 7 MapRequestPayload ⇐ Php

[Anonymous]

Я хочу разобрать запросы JSON во вложенные DTO с помощью MapRequestPayload. Цель состоит в том, чтобы проверить данные в DTO.

Пример JSON:

{ "мета": { "локаль": "гер", «validateOnly»: ложь }, "содержание": { "firstName": "firstName", "lastName": "lastName", "displayMode": "система", "фаворитныемандаты": [ { "mandateId": "{{mandateId}}", "позиция": 0 } ] } } Мета всегда содержит один и тот же набор данных, а содержимое варьируется в зависимости от конечной точки.

Мой первый подход был примерно таким:

используйте Symfony\Component\Validator\Constraints в качестве Assert; последний класс UpdateUserRequestDTO { публичная функция __construct( #[Assert\Valid] public Meta $meta, #[Assert\Valid] public UpdateUserDTO $content, ) {} } используйте Symfony\Component\Validator\Constraints в качестве Assert; используйте CustomConstrains; окончательный класс только для чтения UpdateUserSettingsDto { публичное имя $name; общественная FavoriteMandatesCollection $favoriteMandates; публичная функция __construct( строка $firstName, строка $lastName, #[Assert\IsArray] массив $favoriteMandates, #[CustomConstrains\IsEnumValue(DisplayModeEnum::class)] строка $displayMode, ) { $this->name = Name::fromStrings($firstName, $lastName); $this->favoriteMandates = FavoriteMandatesCollection::fromInputArray($favoriteMandates); $this->displayMode = DisplayModeEnum::fromString($displayMode); } } Проблема в том, что это будет означать наличие двух классов на конечную точку, где разница между классами requestDTO будет заключаться только в типе $content. Хотя это, скорее всего, сработает, это выглядит несколько грязно, особенно если проект станет больше.

Мой второй подход заключался в том, чтобы определить $content как массив (который будет иметь только 1 повторно используемый requestDTO), а затем вызвать конструктор с $dto = new UpdateUserSettingsDto(...$content) при этом подходе я кажется, что-то пропустил, поскольку ограничения не проверены.