Używam Symfony 4 i istnieją niestandardowe zdarzenia i abonenci, np. CustomEvent i CustomEventSubscriber. Istnieje moduł wysyłający CustomEvent, np. CustomModule. I ten moduł używa w kontrolerze (ControllerA) i komendzie (CommandB).

Innymi słowy możliwe dwa następujące scenariusze:

ControllerA -> CustomModule -> CustomEventSubscriber(CustomEvent)

Lub

CommandB -> CustomModule -> CustomEventSubscriber(CustomEvent)

Logika w CustomEventSubscriber trochę się różni w zależności od tego, gdzie został wywołany CustomModule (ControllerA lub CommandB).

Jak przekazać te informacje do CustomEventSubscriber?

Mogę dodać właściwość $context do CustomEvent i ustawić ją w CustomModule. Ale w takim przypadku powinienem przekazać informacje o kontekście do CustomModule.

A może przydałoby się jakieś ustawienia globalne, np. pojemnik?

Albo utworzyć dwóch różnych subskrybentów zdarzeń dla zdarzenia CustomEvent, wyłączyć automatyczne okablowanie i „ręcznie” zainicjować i dodać do dyspozytora w ControllerA i CommandB?

0
Andrey Lebedev 20 listopad 2019, 09:27
Co rozumiesz przez „kontekst”? Czy możesz dodać trochę kodu do swojego pytania, aby było jasne, co dokładnie chcesz osiągnąć?
 – 
yivi
20 listopad 2019, 13:22
W każdym przypadku wszystkie istotne informacje powinny być zawarte w przedmiocie zdarzenia.
 – 
yivi
20 listopad 2019, 13:24
> Przez kontekst rozumiem to samo, co w kontekście normalizacji API Platform [api-platform.com/docs/core/serialization/…, który przechodzi wraz ze zdarzeniem od jednego subskrybenta do drugiego. Zacząłem używać GenericEvent z dodatkowymi argumentami.
 – 
Andrey Lebedev
20 listopad 2019, 14:44
1
Sposobem na to jest przekazanie dowolnych informacji w ramach wydarzenia. Stwórz własne niestandardowe wydarzenie z dowolnymi właściwościami, których potrzebujesz, i tego powinien oczekiwać Twój subskrybent.
 – 
yivi
20 listopad 2019, 14:45
Andrey, czy poniższa odpowiedź ci pomogła? Jakakolwiek informacja zwrotna?
 – 
yivi
23 listopad 2019, 17:45

1 odpowiedź

Nie ma potrzeby tworzenia globali, omijania kontenera ani żadnego innego mechanizmu przeciwdziałającego wzorcom.

Oczywistym miejscem przekazywania informacji z miejsca, w którym zdarzenie jest wysyłane do miejsca jego obsługi, jest samo zdarzenie .

Idealnie byłoby, gdybyś utworzył własną niestandardową klasę zdarzeń , z dowolnymi właściwościami potrzebnymi do wykonania pracy.

Niestandardowe zdarzenie byłoby dostosowane do Twojej aplikacji i możesz ich słuchać bez konieczności sprawdzania z getSubject(), czy odbiornik naprawdę powinien sobie z tym poradzić.

Używanie Generic jest w porządku, chociaż znacznie mniej wyraziste. Jeśli dispatch(new CustomerCreatedEvent()) od razu widać, co się dzieje.

To jest zdarzenie, którego powinien słuchać Twój subskrybent, a zawiera ono już wszystkie niezbędne informacje zebrane w kontekście wysyłania.

1
yivi 21 listopad 2019, 16:38
OK. Jakie plusy i minusy użyć niestandardowego zdarzenia, które rozszerza Event vs GenericEvent?
 – 
Andrey Lebedev
20 listopad 2019, 14:57
Zdarzenie niestandardowe byłoby dostosowane do twojej aplikacji i możesz słuchać tych zdarzeń, bez konieczności sprawdzania za pomocą getSubject(), aby zobaczyć, czy detektor naprawdę powinien sobie z tym poradzić. Używanie Generic jest w porządku, choć znacznie mniej wyraziste. Jeśli dispatch(new CustomerCreatedEvent()) od razu wiadomo, co się dzieje.
 – 
yivi
20 listopad 2019, 15:00
Chodziło mi o stworzenie CustomerCreatedEvent, które rozszerza GenericEvent i mojego subskrybenta oczekującego tego typu zdarzenia. Jak rozumiem, różnica między rozszerzaniem Event a GenericEvent polega na dodatkowych parametrach zdarzenia w postaci właściwości tablicy lub obiektu.
 – 
Andrey Lebedev
20 listopad 2019, 15:11
1
Zajrzyj do vendor/symfony/event-dispatcher/Event.php, aby zobaczyć adnotację o amortyzacji. A ponieważ GenericEvent rozszerza Event, GenericEvent również jest amortyzowany. Nowe wydarzenie jest objęte umowami z dostawcami/symfonami/dyspozytorami wydarzeń
 – 
Cerad
20 listopad 2019, 16:36
1
- Wygląda na to, że się myliłem co do odejścia GenericEvent. 5.0 właśnie został wydany, a GenericEvent nadal istnieje. Po prostu rozciąga się od Contracts\Event. Nadal nie widzę żadnego przekonującego przypadku, aby go używać, ale wygląda na to, że będzie dostępny w nieskończonej przyszłości.
 – 
Cerad
21 listopad 2019, 16:34