Телеграмм чат группы symfony

10:25пожаловаться #1

ПГ

Этот вот flusher (сам его юзаю), честно говоря тоже костыль над доктриной и привязка к ней. По хорошему должен быть как раз какой нить save в репозитории и только. Но опять таки просто так запихать flush в репозиторий не получится из-за глобального UoF

10:33пожаловаться #2

Andrey Dembitskyi in symfony

"костыль" над unit of work

10:35пожаловаться #3

АЯ

в репе сейва не должно быть. в репе должен быть add

10:35пожаловаться #4

АЯ

а вот флаш - "применить все изменения" как раз норм.
это просто разные подходы.

10:36пожаловаться #5

АЕ

Флашер это не только обвязка над доктриновским флашером, там может жить, например, штука, которая релизит события из сущности, чтобы они вылетали в систему в момент сохранения сущностей в БД, ни раньше ни позже. (возможно даже в одной транзакции, если события улетают в шину через БД)

10:36пожаловаться #6

ПГ

Меняем реализацию репозитория где нет этого коммита UoF, как быть?

10:37пожаловаться #7

ПГ

Да понятно это все, Елисеевская реализация.

10:37пожаловаться #8

АЕ

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

10:38пожаловаться #9

ПГ

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

10:40пожаловаться #10

ПГ

Опять таки чем этот save в репо отличается от какого то отдельного flush отдлеьного класса ?

10:42пожаловаться #11

АЯ

1. флаш отдельного класса не должно существовать
2. сейв это вообще не метод репы

10:42пожаловаться #12

АЕ

почему на один агрегат? А если в транзакции затрагивается два?
У одного пользователя списали 10 рублей, другому добавили, уже два агрегата участвуют. Если это делать в разных транзакциях то можно на ровном месте потерять консистентность в БД(либо деньги из воздуха появятся, либо исчезнут вникуда)

10:42пожаловаться #13

ПГ

1. Ваша реализация, где должен быть flush? 2. Спорить не буду, тут конечно да, есть момент что лучше чтобы save не было. Но если разгрести п1.

10:43пожаловаться #14

АЯ

флаш должен быть в конце итерации или перед выходом. типа "сдампить на диск".
другими словами в моём понимании приложение должно работать с объектами в памяти, при необходимости из дотягивая из базы.
и не воспринимать флаш как метод сохранения объектов, а просто как "дамп изменений на диск для повторного переиспольования"

10:45пожаловаться #15

ПГ

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

10:45пожаловаться #16

АЕ

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

10:47пожаловаться #17

ПГ

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

10:47пожаловаться #18

ПГ

@shaman_alex вопрос с счетом кстати интересный, как он должен реализовываться с этим правилом :)

10:50пожаловаться #19

Volodymyr Melko in symfony

ну так не пишите сценариев, гдемодифицируете больше 1 аггрегата, в уов будут только его изменения и все удачно зафлашится =)