Ahoj, chtěl jsem použít \Kdyby\Events, které chci samozřejmě použít kvůli tomu abych se vyhnul závislostem.

Eventy se mi zavolají jak mají, což je super, ale mám problém v tom co s daty které dostanou. Vysvětlý příklad…

Mějme jednoduchý Ticketovací systém (title, description, assigne_id, creator, due_date), rozdělený podle Klientů (name, ico, dic, street, city, etc.), takže máme dvě entity. A teď bych chtěl nad ticketovacím systémem volat dvě Listenery, třeba JournalListener a MailListener.

Takže v TicketService budu mít event $onFinish[], v metodě createTicket() po splnění všech věcí vezmu data se kterými jsem pracoval a pošlu je listenerům, tedy $this->onFinish($this, $data); a teď přichází to co mi nejde do hlavy…

Když to samé udělám v pomyslné ClientService a zavolám tedy $this->onFinish($this, $data); tak by každý ten listener musel buď vědět jak mají vypadat data od každého sendera, tedy TicketService, nebo ClientService a listener by byl sakra velký (úměrně k velikosti aplikace, protože Jurnal by měl logovat všechny potřebné změny), nebo by každá service musela posílat konkrétní tvar dat a to zase porušuje to kdyby chtěl poslouchat i MailListener, protože by dostal uplně jiný tvar.

Interface mi do toho moc nezapadá, enbo mám zkreslené představy o interface, protože třeba z ticketu se jenou pošle to, že se změnil assign_id a podruhé, že byl ticket třeba uzavřen a zároveň si neumím představit jednotný interface pro mailer a pro Journal.

Díky za nakopnutí

Předpokládám, že stále platí o čem jsme se bavili na Posobotě – tedy že se snažíš udělat nad systémem auditování.

Být tebou, velice vážně bych zvažoval automaticky generované triggery. S Doctrine je to hračka vygenerovat takovou věc automaticky, protože máš metadata o všech sloupcích a tabulkách ve SchemaManageru. Prošel bych si tedy tabulky a pro každou vygeneroval proceduru, která bude obsahovat generované SQL na porovnávání hodnot a nějakou inteligentní serializaci do “událostí”, které bude všechny ukládat do nějaké konrétní tabulky (nebo do více). Následně bych vygeneroval triggery, které budou procedury volat. Proč né rovnou do triggerů? Protože mysql umí jenom jeden trigger na jeden typ události na jednu tabulku – když to máš v procedurách, můžeš tam pak snadno přidávat do triggerů další věci – opačně to jde blbě. Díky tomu to bude fungovat vždy a nebude možné to obejít.

Druhá možnost je použít ORM, které vždy ví, jaké změny v entitách proběhly, protože na základě toho generuje SQLka které updatují databázi. Nad Doctrine by mělo být snadné takový jeden univerzální listener napsat, ovšem počítej s tím, že když něco takového budeš dělat na každý flush, tak to bude výkonově něco stát. Další problém je, že doctrina ti tyhle eventy nemá jak zavolat jedna pro data které někdo updatne ručně “přes Adminer” nebo když někdo pustí v aplikaci v DBAL nějaké SQLko napřímo, dokonce ani když voláš DQL, protože ty se překládají také na SQL a bylo by extrémně neefektivní, kvůli každému takovému DQL update query načítat entity do paměti.


You must first log in to participate in this discussion