Как правильно в Symfony десериализовать Request в DTO, а последний потом в сущность?

Question

[Shurik]

Здравствуйте. Задался вопросом как правильно с точки зрения доступных инструментов, кода и архитектуры оптимально преобразовать Request через DTO в сущность.
Допустим есть запрос с параметрами:

{
"name": "Vasya",
"age": 18,
"town": 1
}

DTO cо свойствами:

string $name;
int $age;
App\Entity\Town $town;

и сущность User с некоторыми свойствами, включая те, что есть в DTO.

Хотелось бы узнать ваше мнение как лучше:
1. Из объекта Request параметры запроса на DTO. Если с простыми типами данных все понятно (десериализовать запрос), то как быть с объектами в свойствах (они же отношения в сущностях) где town 1 надо преобразовать $townRepository->find(1)?
2. Как после выполнения п.1, имея заполненный DTO данными запроса, смаппить эти данные на сущность. Писать самому маппер или просто в котнроллере делать типа $user-setAge($DTO->getAge());

Интересует ответ на вопрос с точки зрения лучших практик.
Видел реализации на базе кастомного ParamConvertera. Думаю, также, что можно повесить обработчик события на запрос и там как-то обрабатывать Request, но не уверен, что это правильно. Хотелось сократить время на набивании ошибок и сразу пойти по правильному поту) Понимаю, что есть библиотеки, но помимо советов их хотелось бы узнать и подноготную этого процесса на пальцах. В общем буду рад любым рекомендациям и советам. )

Answer 1

[Виктор Кожухарь]

Как человек, который в своё время так переусложнял код, что потом сам не понимал, что и где в проекте происходит, посоветую вам использовать самый лучший принцип на свете - "KISS"

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

Я бы сделал так:

• В контроллере сериализуем JSON в DTO ( можно вообще вот так https://symfony.com/blog/new-in-symfony-6-3-mappin... )
  
• Далее создаёс сервис, который будет нашим маппером, и который будет иметь 2 метода "fromDtoToEntity" и "fromEntityToDto", и он будет заниматься всеми преобразованиями туда-сюда.
  
• В этом маппере пишем наитупейшую логику, как вы и писали $user-setAge($DTO->getAge());
  
• Отдаём клиенту ответ из контроллера
  

Этот вариант максимально прозрачен и сильно сэкономит вам время при дебаге, потому что вы в два клика сможете найти всю логику.

Comments

[Shurik]

Спасибо за рекомендацию)
А как быть в случае, если в сущности есть свойство-отношение? В DTO делать тип данных c типом данных id сущности (uuid или int, например) или же в DTO пытаться преобразовать входящие данные к типу этого отношения?

[Виктор Кожухарь]

Shurik,
Я считаю, что при создании POST вполне можно использовать в DTO поле с id вложенной сущности, и в сервисе маппере уже подставлять в сущность полную вложенную сущность с таким же id.

А при запросе GET можно либо вообще использовать новый DTO, где в этом поле уже будет развернутый объект, либо вы можете в одном DTO использовать все поля, разделяя их при помощи атрибутов сериалайзера Groups и SerializedName, а чтобы одно и то же поле в JSON было в зависимости от POST и GET либо айдишником, либо развернутым объектом, можно написать собственный нормалайзер для сериалайзера. Это очень просто делается.
https://symfony.com/doc/current/serializer/custom_...

[tukreb]

Зачем писать маппер, когда у симфони уже есть https://symfony.com/doc/current/components/seriali... ?
А если класс не имеет публичный методов или сеттеров, то используйте параметр через рефлексию.

Я же JSON в дто делаю одной строчкой в контроллере:

$dto = $this->serializer->deserialize($request->getContent(), DTO::class, 'json');

А дальше отправляю в готовый useCase ака сервис, где если нужно они обращаются к сущности. В общем напрямую с сущностями я практически не работаю.

[Виктор Кожухарь]

tukreb, Маппер для того, чтобы из DTO преобразовывать в сущность и обратно. Писать это всё прямо в контроллере плохо, потому что в один прекрасный день вам понадобится получить данные не через http, а из очереди, из консоли и т.д. Такое очень часто происходит, поэтому тут от принципа KISS можно на один шажок отступить.

Сериалайзер - компонент мощный, но не всегда он может всё сделать. Поэтому иногда в пограничных случаях для него можно написать свой нормалайзер(денормалайзер), который более тонко будет готовить ассоциативный массив перед тем, как сериалайзер его в JSON перекодирует.

[tukreb]

Виктор Кожухарь, ну я ему и не предлагал писать всё это в контроллере, я тоже за принцип KISS и повсеместно использую его, разбивая всё на простые UseCase которым скармливаю DTOшки.

По его вопросы, он просто хочет сериализовать и нормализировать данные (в частности сущности), поэтому зачем городить огород, когда уже есть компонента от симфони.

[Виктор Кожухарь]

tukreb, Внимательно прочитайте его проблему. У него есть сущность Town, которая связана с сущностью User. И при запросе POST на создание User надо в поле town подставлять ID сущности Town.

Но что же делать, когда надо будет сделать GET User? Тоже выводить просто ID в поле town, и нагружать фронтенд ещё одним запросом на бэкенд, чтобы вытащить полную сущность Town?
А ведь можно при запросе GET в поле town в JSON подставлять не просто ID, а полностью JSON объект Town, с ID, названием, координатами и т.д.
И в этом случае голый Serializer не поможет, и можно написать для сериалайзера свой нормалайзер, который будет подставлять в поле town нужные данные в зависимости от контекста

[Shurik]

tukreb, спасибо за участие в обсуждении. А не могли пояснить терминологию useCase в контексте моего вопроса пожалуйста?

[Виктор Кожухарь]

Shurik,
Тут это долго объяснять. Я очень рекомендую вам почитать про DDD (Domain Driven Design), но не копировать бездумно все его подходы, а забрать оттуда то, что вам покажется интересным. Разделение кода на различные use case - это очень толковая идея.
Упрощённо: это когда весь код, касающийся определенного сценария использования, например, создания нового пользователя, хранится в одной директории. Там и сервисы, и тесты, и интерфейсы и т.д.. И тогда при дебаге вы видите всё прямо перед собой, а не скачете по папкам туда-сюда

[Shurik]

Виктор Кожухарь, спасибо за рекомендации и объяснении. Обязательно почитаю про DDD. Кстати он у меня давно уже где-то в открытых вкладках в браузере "к прочтению", но все руки не дойдут - видимо пришло ее время)))