осталось разобраться как лучше транзакцию использовать в сервисе

если очень надо

Да нет. :)). Просто кто-то такой трейт уже создал. И типа использовать его.

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

осталось разобраться как лучше транзакцию использовать в сервисе

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

брать entitymanager, но завести конвенцию в команде, что кроме как для flush/persist/getReference его не юзать

можно еще сделать свой интерфейс

и проксировать

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

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

брать entitymanager, но завести конвенцию в команде, что кроме как для flush/persist/getReference его не юзать

я завернул в свои сервисы которые делают чисто flush/transactional, а в репках да, конвеншен

я завернул в свои сервисы которые делают чисто flush/transactional, а в репках да, конвеншен

на счет репок я кидал еще недавно статью на блог. что entity manager напрямую инжектить это не айс

когда он закрывается, его переоткрыть нельзя

и беда тогда

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

тут вопрос СУБД. Если ты юзаешь мускуль какой-то, то может стоит вообще UUID юзать? С постгресами например такой проблемы нет - у тебя айдишка будет сразу после persist (то есть add в репозиторий)

когда он закрывается, его переоткрыть нельзя

я завернул его в декоратор

которому можно делать ресет

есть более элегантный способ

есть более элегантный способ

поведаешь?

тут вопрос СУБД. Если ты юзаешь мускуль какой-то, то может стоит вообще UUID юзать? С постгресами например такой проблемы нет - у тебя айдишка будет сразу после persist (то есть add в репозиторий)

ух, а вот это хорошо!

поведаешь?

https://blog.fervo.se/blog/2017/07/06/doctrine-repositories-autowiring/ пхать registry manager и из него получать em

Я даже не думал разделять просто персист и флуш

https://blog.fervo.se/blog/2017/07/06/doctrine-repositories-autowiring/ пхать registry manager и из него получать em

ну то есть чуть-чуть сервис локаторов

ну не, в целом норм

Я даже не думал разделять просто персист и флуш

ну либо ты делаешь и то и то в контроллере либо ты не разобрался с UoW

ну либо ты делаешь и то и то в контроллере либо ты не разобрался с UoW

<?php public function create(ChannelEntity $channel) : ChannelEntity { $em = $this->getEntityManager(); $em->persist($channel); $em->flush(); return $channel; }

<?php public function create(ChannelEntity $channel) : ChannelEntity { $em = $this->getEntityManager(); $em->persist($channel); $em->flush(); return $channel; }

тоже ок, только это будет save метод

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

тоже ок, только это будет save метод

не ок)

ну разве что это контроллер

тогда ок

уже был срач на эту тему

Это репозиторий

А почему не ок?

уже был срач на эту тему

я пропустил видать

А почему не ок?

потому что ты сам сказал что это репозиторий

задача репозитория - хранить. Создавать - не его задача. И уж тем более это не то место где известно что это конец бизнес транзакции, следовательно делать flush там не стоит.

иначе придется потом это учитывать если надо будет создать еще раз эту сущность

по хорошему в репозитории у тебя должно быть что-то такое: public function add(SomeEntity $entity): void { $this->em->persist($entity); }

никаких save

транзакция может быть вложенной, так что ок

и он может уметь делать save

окрамиус это подтвердил кстати

и так в c# и хибер репосах тоже

и так в c# и хибер репосах тоже

ну это разные репосы)

у меня репосы не должны уметь делать save

по хорошему в репозитории у тебя должно быть что-то такое: public function add(SomeEntity $entity): void { $this->em->persist($entity); }

Ок, как тогда делать флуш? Без em

транзакция может быть вложенной, так что ок

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

так что не, спасибо

Ок, как тогда делать флуш? Без em

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

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

Я предполагал делать в сервисе, скорее заверну в сервис em

Спасибо большое!

и так в c# и хибер репосах тоже

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

Я предполагал делать в сервисе, скорее заверну в сервис em

если у тебя по сервису на каждую бизнес транзакцию - то ок

но что-то мне подсказывает что нет)

но если у тебя тупой CRUD - то даже хз

Каждый экшен работает со своим сервисом

Каждый контроллер

так экшен или контроллер?

что делают сервисы? как они называются например

зачем они?)

зачем мы?

Например есть сервис у юзера, там есть метод create, invite

Самое примитивное

А если создавать отдельный класс на каждый юзкейс?

Например CreateUser

да здравствуют команды?)

А он уже в экшн инжектится

типа createAction(CreateUser $useCase)

ну команды там же типа шина команд

а тут просто класс

если у нас правильно выбран aggregate root, то флаш может быть и в репозитории

Например есть сервис у юзера, там есть метод create, invite

нарушение srp, isp

если у нас правильно выбран aggregate root, то флаш может быть и в репозитории

ты часто это видел?)

флаш в репозитории несет больше рисков чем флаш в контроллере. Так же это проще с точки зрения вариантов "как можно сделать не так"

я не спорю что можно если все делать правильно, но делать правильно сложно

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

а если у нас никак не получается с aggregate root, то, есть uow. Можно его или из репозитория дергать или вообще отдельно инжектировать в сервис конкретную реализацию uow для сервиса

когда в uow мы говорим commit мы завершаем логическую транзакцию... ну а реализация делает уже транзакцию в базе

я не понимаю желание запихнуть flush в репозиторий

зачем...

ему там не место

просто даже исходя из сфер ответственности

ну или во всяком случае в том виде в котором это реализовано в доктрине

м... flush - это commit встроенного в доктрину uow

м... flush - это commit встроенного в доктрину uow

да

и там uow по сути глобальный

он никак не изолирован в контексте запроса.

что делает работу с flush дико неудобной.

ну да, по-этому и и говорю, что нужно писать свои реализации uow и их инжектить в сервис.... а они уже на commit будут делать пачку персистов и flush

ну да, по-этому и и говорю, что нужно писать свои реализации uow и их инжектить в сервис.... а они уже на commit будут делать пачку персистов и flush

я бы хотел глянуть на подобную реализацию.

flush в контроллере - это просто, конечно, но до момента, пока тебе не понадобися вложенные транзакции... да и вообще не нравится такой вот вызов чисто persistance ответственности из приложения... хотя и не протеворечит, да

у меня терпения не хватило свой uow писать хоть у меня и была довольно простая задача

flush в контроллере - это просто, конечно, но до момента, пока тебе не понадобися вложенные транзакции... да и вообще не нравится такой вот вызов чисто persistance ответственности из приложения... хотя и не протеворечит, да

профит flush в контроллере в том, что если тебе вдруг понадобились вложенные транзакции, то ты можешь инициировать там первую (вручную) и обозначить конец.

ну то есть это тебя ни в чем не ограничивает

ну у меня нет примеров... я тут погуглил.. ну все кто в лес, кто по дрова... кто-то в репозиторий втфкает его, кто-то вообще сократил uow до трех методов: begin / commit / rollback и инжектит его в сервис (тира uow->begin, repo->add, uow->commit)

ну у меня нет примеров... я тут погуглил.. ну все кто в лес, кто по дрова... кто-то в репозиторий втфкает его, кто-то вообще сократил uow до трех методов: begin / commit / rollback и инжектит его в сервис (тира uow->begin, repo->add, uow->commit)

есть удобная обертка - transactional которая сама хэндлит begin/rollback/commit

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

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

просто разные контексты