В чем разница между DTO vs ValueObject vs Entity на примерах? Правильное именование классов.

[grigori]

@fixxxer, как-раз думаю, что надо расписать на примере.
Надо проверить статус платежа заказа. Состояние платежа доступно по API PayPal или Robocassa.
Получаю детали заказа из базы, в них метод платежа. По методу платежа выполняю стратегию или фабрику, и получаю адаптер платежной системы.
Адаптер надо инъектнуть в модель-проверяльщик, которая по результату запроса сменит поле статуса оплаты заказа в базе.

Можно из адаптера сделать модель, получать из нее статус платежа и передавать в обновляльщик. В дизайне не бывает единственного решения. Но адаптер - это не модель, а сервис, не вижу смысла городить из него сущность.

 

[WMix]

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

 

[Вурдалак]

Когда пишет вмикс я начинаю терять волокно обсуждение пять пять два восемь выкидывает и сохраняет + логичнее (хотя даже в минус).

 

[grigori]

Часто надо не просто принимать платежи и реагировать, а выставлять счета и проверять состояние оплаты.

 

[WMix]

На этапе приема и валидации трудно чтото проверить, пришло, положи клиенту на счет. Разобрался, сторнируй перевод, забери деньги... По мне гораздо хуже, что клиент оплатил, а ожидаемое, в смысле сообщение "вы наш любимый клиент, спасибо за покупку" не получил. Лучше позже, когда проверят люди, написать маил с обьяснением, что пошло не так.

 

[fixxxer]

@grigori, ну будет метод в модели, который аргументом будет ожидать реализацию некоего интерфейса, который и будет реализован этим самым адаптером, DI все еще нет

 

[grigori]

@grigori, ну будет метод в модели, который аргументом будет ожидать реализацию некоего интерфейса, который и будет реализован этим самым адаптером, DI все еще нет

Прости, но ты буквально описал https://en.wikipedia.org/wiki/Dependency_injection#Setter_injection

 

[grigori]

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

и iPhone у жены @Redjik

 

[Вурдалак]

Прости, но ты буквально описал https://en.wikipedia.org/wiki/Dependency_injection#Setter_injection

Имеется в виду double dispatch, т.е. там нет this.foo = foo, это принято различать.

 

[grigori]

@Вурдалак, лучше дай пример, мне сложно догадаться что ты имеешь ввиду под местоимением "это".

double dispatch мне кажется как "в огороде бузина, в городе дядька"
тут нет двух равных сущностей, и не нужен динамический выбор метода, который надо исполнить для реализации их взаимодействия - здесь одна сущность (заказ), и стратегия для выбора способа платежа, обычный single dispatch

 

[Вурдалак]

http://thinkbeforecoding.com/post/2009/03/04/How-not-to-inject-services-in-entities

 

[grigori]

http://thinkbeforecoding.com/post/2009/03/04/How-not-to-inject-services-in-entities

Доказательства кодом буду? Пока похоже на софизм.

* Длинный текст, который наполовину состоит из повторений одного суждения несколько раз, с единственным аргументом "я всегда нахожу способ делать хорошо и не делать плохо". Абстрактно хорошо, и ни одного аргумента почему все-таки инъектить сервис в сущность плохо.
* Вообще не в тему. Я делаю инъекцию сервиса для получения данных в модель, которая обновляет статус, а не в сущность заказа.

 

[Вурдалак]

Вообще не в тему. Я делаю инъекцию сервиса для получения данных в модель, которая обновляет статус, а не в сущность заказа.

Именно поэтому это и нельзя называть «setter injection». Сервис не сетится.

 

[grigori]

Сервис сетится в сервисную часть модели. Из модели более высокого уровня. А можешь перестать повторять "за все хорошее и против всего плохого", и привести псевдокод как правильно? С обоснованием, пожалуйста.

 

[Вурдалак]

Сервис сетится в сервисную часть модели. Из модели более высокого уровня. А можешь для разнообразия подумать прежде чем ругать?

А, ну мы, наверное, должны были до этого догадаться. Я тебе просто объяснил реплику @fixxxer'а, успокойся, попей водички. Твой пост на глазах эволюционирует в попытках меня оскорбить.

 

[grigori]

наоборот, сдерживаюсь, думаю, и понимаю, что double dispatch для данного примера с одной сущностью - это алогизм.

Да и вряд ли fixxxer-у нужен толкователь.
Может, стоит все-таки читать топик, чтобы не противоречить самому себе.

 

[fixxxer]

Я имел ввиду именно double dispatch; еще с евентами сделать можно, но с биллингом мне это кажется слишком неявным.

Сервис сетится в сервисную часть модели. Из модели более высокого уровня.

Что такое "сервисная часть модели" и "модель более высокого уровня"? Я не знаю таких терминов.

 

[grigori]

Что такое "сервисная часть модели" и "модель более высокого уровня"? Я не знаю таких терминов.

Это мунспик, изобретенный для общения с @Вурдалак. К сожалению, на обычном инженерном русском не получается, а язык хип-хопа мне не знаком, я другого поколения.
Напишу пример кода чуть позже.

 

[fixxxer]

Ну, я многие приемы и паттерны много лет использовал, не подозревая, что они как-то называются, так что кодом оно надежнее, да

 

[Redjik]

как то так

    public function createOne(FormFactory $factory, DataPersister $dataPersister, Request $request)
    {
        $model = $this->model->newInstance();
        $dto = $factory->create($this->formName, $this->model->newInstance());
        $dto->setData($this->getRequestData($request));
        if ($dto->validate()){
            $dataPersister->persistModelFromDto($model, $dto);
        }

        return $this->responseFactory->setPayload([$dto, $model])->createFromRequest($request);
    }