Потому что по факту мы из за изменений одной сушьности, изменяет показатель в другой, что не есть хорошо

если сущности принадлежат разным контекстам - то почему бы и нет

если это все в рамках одного контекста - я бы сделал сервис сверху который руководит процессом и декларирует "создай, пересчитай" или "удали, пересчитай"

если сущности принадлежат разным контекстам - то почему бы и нет

То есть получается ты подписываешься на postFlush, там находишь нужную сушьнось, и от туда кидаешь ивент на то что надо пересчитать?

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

То есть получается ты подписываешься на postFlush, там находишь нужную сушьнось, и от туда кидаешь ивент на то что надо пересчитать?

нет, у меня есть сущности с интерфейсом DomainEventProducer и у него есть метод release

и я тупо обхожу все сущности в UoW и собираю ивенты

а потом тригерю. Могу в очередь их запихнуть, могу там же обработать

но

это повторюсь - если у тебя между двумя модулями надо связь организовать. В пределах одного - чем явнее тем лучше

вопрос в том нужно тебе связанность понижать или с ней все ок

ну и смотреть с позиции open/close

там по факту 3 строки + public function updatePropertyRating() + { + $property = $this->getProperty(); + $property->calculateRating(); + $property->save(); + }

Хотя конечно calculateRating в модели не должен находится, это косяк

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

по этому лучше делать через ивенты

Хотя конечно calculateRating в модели не должен находится, это косяк

кто тебе такое сказал

@fes0r а разве в доктрине нет походего функционала который может кидать ивенты?

ну то есть, это не от "в модели/в сервисе" зависит, а просто от того как ты на объекты дробишь и соблюдаешь ли ты принцип информационного эксперта

@fes0r а разве в доктрине нет походего функционала который может кидать ивенты?

доменные ивенты чуть-чуть другая штука

кто тебе такое сказал

Ты думаешь норм что модель достает все ревью который одобрены и считает рейтинг, а потом записывает у себя в переменную?

public function updateSomething() { // do something $this->remember(new SomethingHasBeenUpdated($this->id)); }

Ты думаешь норм что модель достает все ревью который одобрены и считает рейтинг, а потом записывает у себя в переменную?

я бы это SQL запросом делал)

и тогда да - зашить в сервис

у меня к примеру есть логика - надо пересчитать лимиты продавцов

я бы это SQL запросом делал)

Ну там по большому счету ведь не важно как делать? ты же не будешь запрос вы ентите делать?

public function calculateLimits(LimitsCalculator $calculator) { $this->limit = $calculator->calculate($this->id, $this->registeredAt); $this->remember(new MerchantLimitsUpdated($this->id, $this->limit)); }

Ну там по большому счету ведь не важно как делать? ты же не будешь запрос вы ентите делать?

в ивенте - нет. В хэндлере ивента - буду

Ну тут если судить по принципу открытости закрытости, то проперти знает о своих ревью и их рейтингах, поэтому может это делать)

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

Ну тут если судить по принципу открытости закрытости, то проперти знает о своих ревью и их рейтингах, поэтому может это делать)

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

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

Для меня главное чтоб грубо говоря вызов функции пересчета не терялся, и как мне кажется лучший вариант

то запихнуть его в ивент, и ивент вызывать по событию из модели при сейве. или типа того

Для меня главное чтоб грубо говоря вызов функции пересчета не терялся, и как мне кажется лучший вариант

чем тебе не нравится к примеру дергать какой-то сервис после того как ты дернул модель, явно

то запихнуть его в ивент, и ивент вызывать по событию из модели при сейве. или типа того

это очень неявно и лучше так по умолчанию не делать

// Add review // recalculate rating

две строчки кода, явно описывающие что происходит

чем тебе не нравится к примеру дергать какой-то сервис после того как ты дернул модель, явно

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

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

если ты где-то не кинешь ивент или не подпишешься на него - ты не пересчитаешь рэйтинг

ну то есть лучше уж явно это сделать

так намного проще найти ошибку

и не надо прыгать по файлам

что бы отследить что происходит

если ты где-то не кинешь ивент или не подпишешься на него - ты не пересчитаешь рэйтинг

Вот это и произашло, я просто забыл про вызов функции пересчета, а хочется кудато поставить ее так, чтоб ее забыть было нельзя

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

Вот это и произашло, я просто забыл про вызов функции пересчета, а хочется кудато поставить ее так, чтоб ее забыть было нельзя

пиши тесты)

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

у меня алгоритм "как сделать цепочку операций" простой: - Можно ли это сделать явно? Ну то есть описать "сценарий" который декларирует порядок действий в одном месте? Если можно - так и делаем. - Порядок действий хочет зависимости из разных мест и мне не очень хочется что бы зависимости знали друг о друге. Или не хочется делать циклические зависимости. Тогда доменные ивенты.

пиши тесты)

Мне кажется достаточно странные стесты будут

Мне кажется достаточно странные стесты будут

смотря что ты хочешь проверить.

ты же запускаешь код когда работу ведешь?

смотря что ты хочешь проверить.

консольная команда которая удаляет допустим старые отзывы)

еще лайххак небольшой - когда планируешь работу - прописывай критерии приемки. Типа что и как должно работать.

консольная команда которая удаляет допустим старые отзывы)

ну ты то не команду будешь тестить, а какой-то сервис

обычный интеграционный тест по позитивному сценарию

и несколько юнитов которые проверят отдельные элементы

ну ты то не команду будешь тестить, а какой-то сервис

Ну вот получается удас должен быть ReviewServiсe c функцией удалить ревью, который уже помимо удаления будет вызывать и пересчет, верно?

Ну вот получается удас должен быть ReviewServiсe c функцией удалить ревью, который уже помимо удаления будет вызывать и пересчет, верно?

я бы сделал по сервису на операцию. RemoveReviewHandler, AddReviewHandler

но да, как-то так

НО, рейтинг этот как к ревью относится?

я бы сделал по сервису на операцию. RemoveReviewHandler, AddReviewHandler

Этож сколько файлов в итоге получится, там же задача в 2 строки

Этож сколько файлов в итоге получится, там же задача в 2 строки

учи хоткеи твоей IDE.

НО, рейтинг этот как к ревью относится?

Есть дом, у него есть рейтинг который мы смотрим от отзывам с оценками

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

ну то есть сэкономишь ты 1 минуту

и потом потратишь лишние пол часа на то что бы разбираться с логикой

и потом потратишь лишние пол часа на то что бы разбираться с логикой

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

у меня есть проект где чел сделал "ядро" которое должно было ему позволить сделать CRUD не в 5 строчек а в 3. Делал он эту херню неделю. По итогу спустя год что бы разобраться в какой-то мелочи разработчик который после него сидел потратил день. Хотя если бы не эта желания "экономить на строчках" можно было бы логику прописать явно и в целом потратилось бы 5 минут на то что бы разобраться что куда и сделать фичу

ERROR: S client not available

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

так не юзай ивенты)

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

ну то есть смотри.....

так не юзай ивенты)

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

$property->submitReview(Review::builder() ->withAuthor($author) ->withRating($rating) ->withMessage($message) ->build() );

а внутри

public function submitReview(Review $review) { $this->reviews->add($review); $this->remember(new ReviewSubmittedEvent($this->id)); }

а потом

public function onReviewSubmittedEvent(ReviewSubmittedEvent $event) { $propertyId = $event->property; $this->connection->exec('UPDATE properties SET rating = AVG(..)', ['id' => $propertyId]); }

если тебе вообще не надо разделять Updated или Submitted

Ок, спасибо, идею понял

можно обобщить событие до ReviewsChangedEvent

профит

ты тригеры все можешь юнит тестами протестить, что ивент есть

ивенты отработают ТОЛЬКО если транзакция успешно зафлашится

ну и останется проверить простеньким интеграционным тестом что сама операция работает корректно

Ну это уже просто

у меня так например одна и та же операция требуется по 10-ти тригерам с весьма непростой логикой

слушай, а ты такие билдеры используешь?

причем тригеры разные

слушай, а ты такие билдеры используешь?

не понял

Review::builder() ->withAuthor($author) ->withRating($rating) ->withMessage($message) ->build()

или это просто пример из головы)

ну это просто класс ReviewBuilder. Что бы не делать сущность с сеттерами и при этом не делать сущность с миллионом аргументов в контрукторе. Можешь в better java почитать например.

Если лень писать руками - ну можно плагин к шторму написать например))))

ну это просто класс ReviewBuilder. Что бы не делать сущность с сеттерами и при этом не делать сущность с миллионом аргументов в контрукторе. Можешь в better java почитать например.

Не, я понимаю, я имею ввиду у тебя есть такие билдеры в реальном проекте?

да

У меня просто както так public static function createBlockout(Period $datePeriod, Property $property, String $description, User $user, $status): Booking {

все что имеет больше двух аргументов в контрусторе стараюсь для таких вещей делать билдеры

потому что где 3 там станет 4

а где 2 - далеко не всегда становится 3

Есть логика

больше кода приходится писать