Как в Symfony загрузить DTO в Entity?

Question

[okkkman]

Всем привет.

Необходимо было отвалидировать данные из DTO и я написал Resolver, который отрабатывает до Controller и взаимодействует с Request. В нем я заинжектил Serializer (для загрузки Request данных в DTO) и Validator интерфейсы соответственно.

Далее мне нужно было DTO загрузить в Entity и при этом учесть вероятность того, что поля между ними могут отличаться.

Для этого написал EntityDtoLoader, своеобразную хурму, которая сверяет существующие set методы и в случае совпадений загружает свои:

protected function load($dto, $model)
{
    $modelMethods = get_class_methods($model);
    $dtoMethods   = get_class_methods($dto);

    foreach ($dtoMethods as $method) {
        preg_match('/get(.*)/', $method, $name);

        if (count($name)) {
            $name = $name[1];

            foreach ($modelMethods as $modelMethod) {
                if ($modelMethod === 'set'.$name) {
                    $model->{'set'.$name}($dto->{'get'.$name}());
                }
            }
        }
    }
}

Минусы у этого решения очевидные.
В общем, лютая дичь.

Обычно люди загружают свою Entity модель из DTO данных ручками, пишут в сервисе "new User" и set'ают данные..

Зря я написал EntityDtoLoader?
Может надо использовать ModelMapper?
Или как лучше?

Можете поделиться вашим подходом? Может у кого есть подходящий репозиторий с примером реализации?

Спасибо

Comments

[sl0]

А dto приходит в виде json'a со стороны или как?
Я не могу понять зачем это вообще нужно. Если ситуация такая, что любую dto нужно маппить на любую сущность, то такой вариант вполне норм, как мне кажется.
Если же нужно конкретный объект смаппить на конкретную сущность, то можно все сделать проще. Хотя бы через тот же datamapper.

[Flying]

Я обычно делаю примерно так:

class Entity {
  // ...
  public static function fromDTO(DataObject $dto) : self 
  {
    $entity = new self();
    // и здесь уже наполняю новый экземпляр данными из dto
    return $entity; 
  }
}

Это позволяет сосредоточить логику передачи данных DTO -> Entity в одном месте

[Flying]

Да, забыл ещё один момент: поскольку этот код находится внутри класса Entity то в нём можно напрямую обращаться к приватным свойствам вновь созданной $entity, а значит не нужно делать кучу setter'ов которые могут привести entity в неконсистентное состояние.

Answer 1

[Максим Федоров]

Вообще это плохая практика — маппить на сущность дто.

Почему: сущность — некоторый бизнес-обьект, он контролирует переходы состояния и инкапсулирует саму логику. Но сущность находится в контексте... бизнес-процесса, который выражен некоторым др видом классов (интеракторы или use cases, если терминами Боба Мартина), например в CQRS таким родом классов являются хэндлеры команд.
Итог: с сущностями напрямую скорее не стоит работать, тем более в сущностях не должно быть сеттеров :) и методов превращения данных из дто в явном виде ака fromDto(), как указал Flying (при всем моем уважении), тк это не бизнес-логика, а некоторая транспортно-приложенческая... Статические конструкторы могут быть, но не для дто, а для определенных данных, отображающих бизнес-возможность.

Кроме того, ваше решение чревато высокой связанностью — ваши сущности конструируются под дто, дто под сущности...

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

Comments

[Flying]

Во-первых спасибо за разъяснения, все мы учимся :)

Тем не менее, для того чтобы мне самому лучше разобраться в вопросе - хотел бы попросить вас прояснить следующий момент (или ткнуть носом туда где можно почитать по этому вопросу подробнее): сущности нам рано или поздно всё равно необходимо создавать. При отсутствии setter'ов (с чем я полностью согласен) очевидно, что при исключении фабричных методов (как было в моём примере) у нас по-идее остаётся два пути: либо передача данных в конструктор напрямую либо создание "пустой" entity и перевод её в нужное состояние через вызов соответствующего метода.

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

Был бы очень благодарен за более подробный комментарий.

[Максим Федоров]

Flying, очевидный способ — конструктор, но очевидно, что создание (не восстановление, а именно создание) сущности может проходить более чем одним путем, потому статические конструкторы норм в условиях отсутствия перегрузки методов.

НО!

• Первое. Создание из ДТО — семантически неверно, тк это абсолютно равносильный путь с сеттерами, тк в ДТО может быть набор данных под один или несколько инвариантов, а то и вообще не валидный набор, а проверить валидность может быть трудоемкой, тк набор в дто под несколько инвариантов.
  
• Второе. Создание из ДТО неверно по слоям, тк мы учим работать сущность с некоторым реквестом, обобщенным и этот факт важный, по сути мы прячем детали входных аргументов от самой сущности и не понятно зачем мы это делаем! Тк разные сценарии создания сущности обычно в разных бизнес-процессах, а ДТО — хак для создания всеми путями, крч как сеттеры, как придумаем, так и создадим...
  
  Пример:
  - создание юзера через емейл https://github.com/ElisDN/demo-project-manager/blo...
  - создание юзера через соцсеть: https://github.com/ElisDN/demo-project-manager/blo...
  
  А создание через ДТО открывает пути создания "как угодно" на подобие "сеттерами наконфигурирую". Например Payment создавать сразу held-состоянии или refunded или canceled
  
  Иными словами — создание сущности через ДТО нужно контролировать оочень тонко, чтобы в ДТО не попали инварианты валидные, но таких состояний, которые контролируются самой сущностью... такие инварианты должны ВОССТАНАВЛИВАТЬСЯ, потому дата-маппер использует для этого рефлексию и некоторые практики идут к тому, что маппинг Value Objects в Doctrine\Types тоже должны через рефлексию делаться, а не через методы как мы делаем обычно...
  
  Ну и вообще, ДТО — транспорт в приложении, бизнес-сущность — чистейшая логика, точно о транспорте с др слоев не должно быть знаний.
  
  

извиняюсь, если очень не понятно раскрыл
ну и речь про ДДД практики, для крудов, ясен-красен, все это не нужно :)

[Максим Федоров]

Flying, крч, createFromDto($obj) == createFromOuterKnowledge($obj)

тогда как по примерам выше createFromEmail($id, $email) и createFromNetwork($id, $network, $identity) уже про детали бизнес-логики

[Flying]

Большое спасибо, пойду разбираться дальше :)

[BoShurik]

Крайне не рекомендую использовать автоматические мапперы. Был опыт использования https://github.com/mark-gerarts/automapper-plus (денормалайзер - туда же) но столкнулся, во-первых, с усложненным конфигом для нестандартных случаев и, во-вторых, невозможностью нормально рефакторить код, т.к. неизвестно где какие поля используются

Answer 2

[index0h]

Зря я написал EntityDtoLoader?

Кто знает, вероятно зря.

Или как лучше?

Сложно сказать, пока что я не совсем понимаю, зачем вам в принципе DTO?
У вас экшн знает какие данные из Request обрабатывать - вытягивайте их явно и проверяйте, да кода больше, но на лонг ране это очень упрощает жизнь, вы явно видите где и что есть.
Дальше, если нужно запихиваете куда нужно.

Есть еще вариант - под каждый экшн сделать отдельный класс *Form / *Message, который на вход получает Request, прям в конструкторе вытягивает данные, валидирует их и запихивает к себе в приватные свойства, преобразовав типы. Наружу предоставляются геттеры.