Události Kdyby/Events v Kdyby/Doctrine

1. Ten $eventArgs objekt má metodu getEntity(), nad kterou si můžeš udělat instanceof check.
2. Nejsnáz přes neon konfiguraci. Uznávám, že v dokumentaci kdyby/events je to trochu schované, ale je to tam :)

inak neviem ci je dobre riesenie pouzivat lifecycle eventy v logike aplikacie, snazim sa tomu vyhybat :)

@Fafin podělím se o řešení, jak řeším eventy v Entitách já – neříkám, že je to perfektní, ale zatím mi vyhovuje, za jakékoliv návrhy jak to vylepšit budu rád.

Používám kombinaci entity listenerů a subscribery.
Pro ukázku mějme entitu Article a chci stopovat, kdy si ji nějaký uživatel přečetl (otevřel).

class Article
{
	/** @var User[] */
	public $readByUsers = []; // pro zjednodušení nechávám public

	public function readByUser(User $user)
	{
		$this->readByUsers[] = $user;
	}
}

Sem je to zatím OK a mám pocit, že nemíchám doménu s infrastrukturou a kód bude v pohodě fungovat i bez ORM (Používám XML mapping).

A teď začíná magie :-). Zaregistruji si listener pro article entitu, nastavim entitě v xml tento listener atd..

services:
	- Listeners\ArticleListener

class ArticleListener
{
	use SmartObject; // Kvůli nette eventům

	public $onReadByUser = [];


	public function preFlush(Article $article)
	{
		foreach ($article->readByUsers as $user) {
			$this->onReadByUser($this, $user);
		}
	}

PS. kdyby někdo věděl, jak v PhpStormu na řádku $this->onReadByUser(..) zrušit čistě pomocí anotací warning Method ... not found in ArticleListener budu rád!

V tomto stavu mám listener, který vyvolává event, ale ještě nemá nastaven žádný handler. Samozřejmě jsem si přes DI mohl v konstruktoru předat závislost a rovnou zpracovávat v listeneru, to se mi ale nelíbí, proto využiju Kdyby\Events a vytvořím si subscriber.

class ArticleReadSubcriber implements Subscriber
{
	private $myService;

	// constructor, předání závislostí ..

	public function getSubscribedEvents()
	{
		return ["Listeners\ArticleListener::onReadByUser"]; // Zde by se dala využít konstanta
	}


	public function onReadByUser(Article $article, User $user)
	{
		$this->myService->addToLog($article, $user);
	}
}

Bohužel je tam tedy ta závislost v listeneru na ORM eventu preFlush(), ale toto řešení mi velmi dobře funguje.

TLDR. listenery používám jen jako prostředníka pro vytvoření „opravdového eventu“, který pak zpracuji pomocí Kdyby\Events.

Editoval Jan Mikeš (21. 10. 2016 11:41)

@jiri.pudil nice, diky! ;)

Díky @Fafin ! O tomto způsobu řešení eventů v entitách jsem četl, ale chyběla mi praktická ukázka. Opravdu se mi to líbí a nechám se inspirovat.

Zatím používám a nejsem spokojen :-(

Můžeš ještě zkusit nastínit proč nejsi s aktuální situaci spokojen a jak by se dalo řešení případně ještě vylepšit?

Btw, symfony eventdispatcher zatím nepoužívám, proč musíš obalit eventy ještě symfoním eventem? Předpokládám, že to je tím, že eventdispatcher očekává jako parametr instanci SymfonyEvent?

Editoval Jan Mikeš (24. 10. 2016 8:50)

@Fafin četl jsi jsi DDD in PHP? Je zde zmíněn způsob, jak to udělat tak, jak popisuješ, ale nejsem si jist finální implementací v Nette.

Např. takto by vypadala simulace registrace uživatele (příklad převzat z knihy):

class User
{
	public function __construct()
	{
		// Nelíbí se mi ten statický přístup k něčemu globálnímu, ale existuje čistější řešení?
		DomainEventPublisher::instance()->publish(new UserRegistered($this->userId));
	}
}

Samotná implementace DomainEventPublisher pak vypadá takto:

class DomainEventPublisher
{
	private $subscribers;

	private static $instance = null;


	public static function instance()
	{
		if (null === static::$instance) {
			static::$instance = new static();
		}

		return static::$instance;
	}


	private function __construct()
	{
        $this->subscribers = [];
    }


	public function __clone()
	{
		throw new \BadMethodCallException('Clone is not supported');
	}


	public function subscribe(DomainEventSubscriber $aDomainEventSubscriber)
	{
        $this->subscribers[] = $aDomainEventSubscriber;
    }


	public function publish(DomainEvent $anEvent)
	{
		foreach ($this->subscribers as $aSubscriber) {
			if ($aSubscriber->isSubscribedTo($anEvent)) {
                $aSubscriber->handle($anEvent);
            }
		}
	}
}

Mimochodem tebou zmíněné řešení jsem našel i zde (trait HasEvents) a právě se rozhoduji který z těchto 2 přístupů použít, singletony mi jsou ale tak nějak proti srsti, takže mám trošku vnitřní blok :-).

Co konkrétně mi není jasné u DomainEventPublisheru je, jak všechny subscribery přihlásit k odběru? Napadlo mě, že by subscribery měly být zaregistrované jako služby a při jejich registraci (jak?? v konstruktoru? v configu pomocí - setup() ??) do DI takto:

class SendUserRegistrationEmailSubscriber implements DomainEventSubscriber
{
	public function __construct()
	{
		DomainEventPublisher::instance()->subscribe($this)
	}
}

K tomu se váže zároveň i další otázka, šel by ten publisher registrovat taky do DI jako služba? (zatím jsem nezkoušel), abych jej pak mohl vyžadovat v závislostech, případně ručně předávat:

services:
	eventPublisher: DomainEventPublisher::instance()
	- SendUserRegistrationEmailSubscriber(@eventPublisher)

Pak bych totiž mohl využít něco takového:

services:
	- SendUserRegistrationEmailSubscriber
	eventPublisher:
		class: DomainEventPublisher::instance()
		setup:
			- subscribe(@SendUserRegistrationEmailSubscriber)

Zatím zkouším modelovat pouze doménu, infrastrukturu a aplikační vrstvu neřeším ještě vůbec, proto budu rád za jakékoliv rady a zkušenosti s tím, jaké nástrahy mě budou ještě čekat a případně jak se jim vyhnout.

edit: částěčně si odpovím na některé otázky sám :-)
Tento zápis se zdá být funkční:

services:
	eventPublisher:
		class: DomainEventPublisher::instance()
		setup:
			- subscribe(PersistDomainEventSubscriber)

	- PersistDomainEventSubscriber

Zůstávají tedy otázky spíše na to co je čistější a vhodnějším řešením, jestli volání staticky singletonu z entity je čistější než to, aby si entita udržovala eventy v sobě a ty byly zpracovávány infrastrukturou.

Editoval Jan Mikeš (25. 11. 2016 15:13)