Doctrine2 – Lifecycle eventy

Ahoj,

narazil jsi na klasický problém s oddělením doménové logiky od persistence. Je super, že jsi na to šel přes továrnu, ale chápu obavy, že se tomu někdo časem vyhne. Stejně tak je dobře, že jsi zvažoval Doctrine lifecycle eventy, ale jak správně zmiňuješ – volat flush() v rámci flush() je nebezpečné a obecně se jejich používání na aplikační logiku nedoporučuje.

✅ Doporučené řešení: Event dispatcher

Robustní a dlouhodobě udržovatelné řešení je použít event-driven přístup – např. Symfony EventDispatcher nebo obdobný mechanismus (klidně vlastní jednoduchý). Myšlenka je následující:

1. Továrna vytvoří komentář a vyvolá událost

class CommentFactory
{
    public function __construct(
        private EntityManagerInterface $em,
        private EventDispatcherInterface $dispatcher,
    ) {}

    public function addComment(User $user, string $text): void
    {
        $comment = new Comment($user, $text);
        $this->em->persist($comment);
        $this->em->flush();

        $this->dispatcher->dispatch(new CommentCreated($comment));
    }
}

2. Listener na CommentCreated

class CommentCreatedListener
{
    public function __construct(
        private FooService $fooService,
    ) {}

    public function __invoke(CommentCreated $event): void
    {
        $this->fooService->doSomeMagic($event->getComment());
    }
}

3. Registrace listeneru

Podle toho, co používáš:

• v Symfony přes services.yaml (nebo autokonfiguraci),
• v Nette přes services.neon,
• nebo čistě PHP-style registrací.

Tímto způsobem máš perfektně oddělené:

• doménovou logiku (tvorbu komentáře),
• reakci na události,
• a hlavně jsi mimo Doctrine lifecycle eventy, které jsou „magické“ a hůře testovatelné/udržovatelné.

🛡 Navíc: Kontrola závislostí pomocí Deptrac

Pokud tě trápí, že někdo začne volat FooService::doSomeMagic() nebo EntityManager::flush() napřímo tam, kde by neměl, doporučuju podívat se na Deptrac. Ten ti umožní definovat pravidla mezi vrstvami aplikace (např. „Controller nesmí volat Repository přímo“, apod.), a v CI si to můžeš i automaticky hlídat.

---

Instruovano pres AI.

@ViPEr*CZ* v takom prípade by stačilo prehodiť flush() úplne nakoniec a v doSomeMagic vôbec flush() nevolať:

class CommentFactory
{
    public function __construct(
        private EntityManagerInterface $em,
        private EventDispatcherInterface $dispatcher,
    ) {}

    public function addComment(User $user, string $text): void
    {
        $comment = new Comment($user, $text);
        $this->em->persist($comment);

        $this->dispatcher->dispatch(new CommentCreated($comment));

        $this->em->flush();
    }
}

@fordo.pytlik

mám články a komentáře, a pokaždé se přidá komentář, tak je potřeba provést X kroků.

potřebuješ zajistit „orchestraci“ složitějších scénářů v doménové logice, jsou dva základní přístupy:

a ) Event Driven přístup (Domain Events)

– komentář vyvolá doménovou událost CommentCreatedEvent
 – event dispatcher rozešle událost listenerům CommentCreatedListener
 – listenery provádějí jednotlivé akce prostřednictvím specializovaných tříd – Mailer, jiné repository, ..

zde je primární business logika zapouzdřena v repository a vedlejší účinky (emaily) se obsluhují událostmi

b ) Servisní třída (Application Service, Domain Service)

všechny související akce doménové logiky („provést X kroků“) se řeší v samostatné třídě, Domain Service je koncept, kdy servisní třída obsahuje primárně doménovou logiku, zatímco Application Service se více zaměřuje na orchestraci různých systémů.

Event Driven koncept se doporučuje pro aplikace podléhající změnám a rozšiřování, zatímco servisní třídy pro méně složité scénáře, kde potřebuješ jasné řízení procesu.

Teď k Tvému kódu, do třídy CommentFactory Jsi zapouzdřil scénář vytvoření komentáře a následující kroky, třída má suffix Factory, což zní divně. Factory je koncept zapouzdření inicializace objektu do samostatné třídy. Třída CommentFactory ale zajišťuje orchestraci scénáře „provést X kroků“ včetně zápisu do databáze. Více by se hodil suffix Service (Facade ?).

Jsou ale i jiné cesty – např. cesta guru OOP Martina Fowlera bohatý doménový model, kdy repository samo rozhoduje vše co souvisí s logikou jeho entity, může i odesílat emaily, a máš to vyřešené. Nebo ty koncepty kombinovat, zapouzdřit „X kroků“ které pracují s entitou do repository a odeslání emailu jako „side effect“ řešit eventem !

Pokud je scénář „X kroků“ komplexní a pracuje s různými entitami, je asi lepší ho umístit do samostatné servisní třídy.

Editoval m.brecher (21. 5. 16:56)

jak může komentář vyvolat event? když entita nemá závislosti

Entita ne, ale repository ano:

class CommentRepository extends ServiceEntityRepository  // doporučeno v Doctrine
{
    public function __construct(
	    private readonly EntityManagerInterface $entityManager,
	    private readonly EventDispatcherInterface $eventDispatcher,
    )
    {}

    public function addComment(Comment $comment): void
    {
        $this->entityManager->persist($comment);
        $this->entityManager->flush();
        $this->eventDispatcher->dispatch(new CommentCreatedEvent($comment));   // vyvolání eventu
    }
}

Já osobně problém vnímám právě v tom, že mi nic nezabrání v tom, abych omylem neupravil komentář přímo v komponentě (tj. nezavolala se funkce doSomeMagic()). To je právě moje otázka, jak to udělat, abych na to nezapomněl.

Primárně bys měl kód postavit tak, aby byl v souladu s DDD principy, které ale umožňují různé koncepty. A hlavně, kód by měl být čitelný a srozumitelný, což by právě DDD měl zajistit. Mám obavu, že když pověsíš event na ukládání Comment-u do databáze, tak v komponentě nebude patrné, že se něco děje. Sice máš zajištěno, že ať vytvoříš Comment kdekoliv, vždy se vykoná „X kroků“, ale není to ideální.

Domain Service

Mě přijde lepší použít pro kód „X kroků“ CommentService, který by to zapouzdřil a v handleru komponenty (processForm) by Jsi volal CommentService.

Nebo jednoduše kód „X kroků“ umístit v handleru komponenty formuláře. Je to přehledné a nejde pak udělat chyba, když by někdo smazal $foo->doSomeMagic() tak ví co dělá, a nedělá to omylem, ale není to elegantní DDD.

Domain Event

Martin Fowler předložil koncept Repository Pattern, ve kterém říká, že repository je mostem mezi doménovou logikou (Entity, Domain Service) a databází. To je v rozporu s tím co navrhuji – odpálit event v repository. Ano, event v repository je na hraně, čistý event bez jakýchkoliv podmínek nebo dalších kroků je ještě „pattern“, ale jakmile by Jsi podmínil vyvolání eventu nějakými podmínkami (logika), už to bude „antipattern“, protože v repository by neměla doménová logika být.

Takže ano, můžeš v repository vyvolat event a ten zpracovat pomocí dispatcheru a listeneru, ale má to nevýhody v méně čitelném kódu, na hraně mezi patternem a antipatternem. Koho napadne, že v repository je skryto „X kroků“ ?

Martin Fowler totiž v konceptu Domain Event navrhuje jiný koncept eventů, vyvolávat eventy, které jsou součástí doménové logiky v Domain Service, nikoliv v Repository:

– repository se stará o persistenci
 – doménová služba po flush() vyvolá event
 – event listener na event reaguje

Toto je koncept, který vede na přehledný kód, byť to možná neřeší to „zapomenutí“. Když vyřešíš zapomenutí eventem v repository, bude to trochu na škodu kvality architektury kódu, je to na výběr, co Ti víc vyhovuje.

Editoval m.brecher (24. 5. 20:49)

PHP 8.4 + lazy služby a kolekce služeb implementujících interface v nette/di = přímé volání, podpora v IDE i PHPStanu. Nepotřebuješ nic než foreach a volání metody z interface. Eventy jsou složitý a za mě už přežitý koncept. Přemýšlet o službách jakožto o přímo volaných akcí, které si volají své dílčí akce vede k mnohem jednoduššímu kódu.

@Felix

U vás ve firmě používáte v PHP aplikacích custom eventy pro vykonání „X kroků“ po nějaké akci ? Pokud ano, tak by mě zajímalo, jak máte vyřešeno odpalování custom eventů – v Domain Service třídě, v Repository, nebo složitějším postupem např. pomocí Doctrine Event Listener ??

U eventů které se odpalují někde mimo business logiku vidím jako problém sníženou čitelnost kódu, protože v hlavní větvi zpracování akce presenteru není v kódu vidět, že se vykoná nějaký další kód. Pokud se ale custom event odpálí uvnitř business logiky (Domain Service) je to koncept Domain Event (Martin Fowler) a kód čitelný je.

Editoval m.brecher (27. 5. 15:14)

m.brecher napsal(a):

@Felix

U vás ve firmě používáte v PHP aplikacích custom eventy pro vykonání „X kroků“ po nějaké akci ? Pokud ano, tak by mě zajímalo, jak máte vyřešeno odpalování custom eventů.

My pouzivame CQRS.

/**
 * @extends BaseCommand<Sitemap>
 */
final class CreateSitemapCommand extends BaseCommand
{

    public function __construct(
        public string $id,
        public string $source,
        public string $url,
    )
    {
    }

}

#[AsMessageHandler]
readonly class CreateSitemapHandler
{

    public function __construct(
        private EntityManagerInterface $em,
        private EventDispatcherInterface $ed,
    )
    {
    }

    public function __invoke(CreateSitemapCommand $command): Sitemap
    {
        $sitemap = new Sitemap(
            $command->id,
            $command->source,
            $command->url,
        );

        $this->em->persist($sitemap);
        $this->em->flush();

        $this->ed->dispatch(new SitemapCreatedEvent($sitemap));

        return $sitemap;
    }

}

Vypada to zhruba takto. Pouziti je pres command/query bus.

$this->bus->handle(new CreateSitemapCommand(...));

Bez eventu si to nedokazu predstavit v dnesni dobe prave. Bez eventu realne nejde delat, podle moji zkusenosti, moduly/pluginy.

Kdyz vystrelim event, tak mi je realne jedno jestli na nej nekdo posloucha a nebo ne-e. Dokonce to v tu chvili ani nemusim vedet, protoze se to muze registrovat dynamicky podle nastaveni, env, ab-testovani, atd.

Marek Bartoš napsal(a):

Kdyz vystrelim event, tak mi je realne jedno jestli na nej nekdo posloucha a nebo ne-e. Dokonce to v tu chvili ani nemusim vedet, protoze se to muze registrovat dynamicky podle nastaveni, env, ab-testovani, atd.

Totéž se dá říct i o kolekci služeb. Prázdné pole v cyklu nevadí, listener a služba se afaik registrují naprosto totožně.

Jop, ja to nikomu nenutim. Zajimalo me jestli se od toho odvracis ty a nebo frameworky a komunity. V ramci firmy bych rad drzel co nejvice mainstream, aby byl hiring co nejvice uspesny.