[qwelukasz]

#symfony2 #symfony #php

Mam encje Exchange która zawiera przelicznik waluty (dodawne przez admina/moderatora).
Chce aby przy każdym dodaniu (postPersist) oraz po każdej edycji (postUpdate) uruchamiana była akcja/skrypt który dla danej waluty przeliczy w bazie prowizje ze sprzedaży.

Zrobiłem to na event listenerze ale w takim wypadku ten event bedzie uruchamiany przy każdej edycji encji - nie tylko Exchange. Czy macie jakieś inne pomysły jak temat ugryźć? (wywoływanie aktualizacji danych w kontrolerze klasy zostawmy na tę chwilę na boku)

[slave89]

@qwelukasz: w Listenerze sprawdzasz instanceof Exchange

[MacDada]

@qwelukasz: domain events

[pitu120]

@qwelukasz: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#entity-listeners-resolver
?

[qwelukasz]

@slave89: tak wlasnie robie

[slave89]

@pitu120:

@EntityListeners({"UserListener"})

Dzięki, tego nie zauważyłem jak dodali.

[Jurigag]

@qwelukasz: taką pierdołę to bym dodał po prostu w klasie entity korzystając z adnotacji, im mniej plików php, obiektów i klas tym lepiej @slave89: @MacDada:

[D.....8]

@Jurigag: ale taguj #januszeoop ( ͡° ͜ʖ ͡°)

[Jurigag]

@Damian1998: ale co mam tagować ? tagi nie działają w komentarzach, php rządzi się swoimi prawami, im mniej obiektów i klas tym lepiej, bo przez to masz ładowanie kolejnego plik, nawet opcache ma to wpływ na wydajność, do takiej pierdoły tworzenie klikulinijkowej funkcji i klasy to idiotyzm

[Jurigag]

@qwelukasz: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html @Damian1998: @MacDada: @slave89: ja bym skorzystał z Lifecycle Callbacks i tyle, jeśli jego kod tego listenera miałby się w przyszłości rozrąsnąć do bardziej skomplikowanej klasy no to wtedy okej, ale jeśli będzie to zawierało jedną metodę która będzie robiła jedną rzecz, no to jest to idiotyzm tworzenie nowego pliku i klasy

z listenerów jako oddzielnych klas bym korzystał wtedy gdy ma to nasłuchiwać kilka klas i

[slave89]

@Jurigag: wydajność to jedno, czytelność to drugie, łatwość rozbudowy to trzecie. Nie chcę robić benchmarka pod ten przykład, ale moim zdaniem dodatkowa klasa jakoś tragicznie tego nie zwolni, a czytelność moim zdaniem będzie wyższa (wchodzisz w bundla i widzisz, że są listenery bez zaglądania do plików encji). Ale to tylko moje zdanie.

Ale zgadzam się z Tobą, że wszystko zależy od tego co będzie w tle robione. Nie wszystko w encji

[Jurigag]

@slave89: zgadzam się że nie zwolni i czytelność będzie wyższa, ale jak będziemy dla każdej pierdoły tworzyli oddzielny listener i się okaże że dla każdego entity będzie oddzielny listener - no to wtedy jakiś tam wpływ na wydajność to zacznie mieć

jeśli będzie to rozszerzał, dodał nowe metody tam, czy będzie ten listener nałuschiwał np jakąś inną klasę - no to wtedy zgadzam się - robimy listenera, jeśli ten kod do

[L.....k]

@Jurigag: wszystko spoko, jak będziesz w tej metodzie operował tylko na tej encji. Ale jak będziesz chciał użyć tam np jakiegoś serwisu to wyjdzie dramat. Widziałem już taką apkę, gdzie jakiś agent dopisał sobie setContainer i wstrzykiwał container wszędzie tam, gdzie spodziewał się, że odpali się update. Tragedia. Ale do operacji na jednej encji sam używam przy prostych funkcjach.

[Jurigag]

@Lisek-Chytrusek: no oczywiście, jeśli będzie potrzebował dostępu do kontenera czy em w tym miejscu to jest to słabe

[DanioPL]

@qwelukasz: dobra rada - nie używaj doctrinowych eventów, one służą do zupełnie czego innego niż logika biznesowa, napisz sobie własny event, obsłuż go event listenerem z symfony, zrób to w miarę jawnie, a nie doctrinową magią, bo potem dostaniesz raka debugując te wszystkie doctrinowe eventy