Hejka, zalozmy ze mam 20 roznych Entity. Dla kazdej Entity chce stworzyc Voter by zarzadzac co kto moze kasowac/edytowac/itp.
Tak wiec tworze 20 voters, rejestruje je jako service.Wszystko dziala wysmienicie ale jest jedno ale. Symfony tworzy wszystkie 20 obiektow voters dla kazdego request, nie wazne czy ja zamierzam z nich korzystac czy nie. Poczytalem troche, ok, rozumiem czemu.
Nie mniej jednak nie podoba mi sie, iz za kazdym razem tworzy mi te 20 obiektow nawet jak nie potrzebuje ani jednego z nich. Oczywiscie moge latwo ograniczyc, by one nic nie sprawdzaly jak nie ma potrzeby wiec nie beda mi obciazac aplikacji zbednymi wyliczeniami ale sam fakt, ze sa one tworzone bez sensu mnie irytuje.

No i pytanie: czy powinieniem sie poprostu nie irytowac i olac to i zostawic jak jest czy moze powininiem cos zrobic?
Przykladowo mysle nad takim rozwiazaniem, ze tworze i rejestruje tylko jeden uniwersalny voter dla wszystkich Entity i w przypadku gdy bedzie żądanie sprawdzenia praw dla jakiejs Entity to dopiero wtedy bede ladowal wlasciwy voter dla tej entity jako zwykly niezarejestrowany obiekt.

Jak wy to robicie u siebie?

A nie myślałeś nad użyciem/przetestowaniem takiego: https://symfony.com/doc/current/service_con...y_services.html ?

To nie zadziala w przypadku voters, gdyz dla nich mechanizm jest taki, ze symfony laduje wszystkie voters jakie sa by moc realizowac swoja wewnetrzna polityke.

To samo zaproponowal poprzednik.
Ale zrozumcie, ze symfony w przypadku voters ma taki mechanim ze laduje je wszystkie bo musi ladowac by realizowac swoje cele. Symfony nie wie jaki voter bede potrzebowal. Symfony laduje wszystkie voter i to votery wiedza czy maja obslugiwac dana akcje czy nie. Dlatego nie da sie tu uzyc LAZY service

Mnie to nie irytuje, ten mechanizm jak dla mnie jest ok. Zastanów się czy nie możesz w takim wypadku stworzyć bardziej ogólnego votera.

Moglbym, ale wowczas trace te przejrzystosc: Jedno Entity -> Jeden Voter do zarzadzania

Ja po prostu strasznie nie lubie tworzyc obiektow, ktorych nie bede uzywal. Ja wiem, ze te kolejne "20" obiektow to cale nic w porownaniu do tego ile Symfony tworzy obiektow po drodze nie mniej mnie to irytuje bo to kolejne "20" obiektow tworzonych na daremno

Symfony stoi w przeciwieństwie do tego stwierdzenia

Nie wiem jak wygląda Twój kod, ale jak to ma się do zasady DRY?

Czemu uwazasz ze bede sie powtarzal?
Dla jednej Entity moge miec jedna zasade a dla innej inna.
A dla tych dla ktorych bede mial te same zasady mam klase bazowa Tylko jak jakas Entity bedzie sie chciala wylamac to wtedy bedzie sobie dziedziczyc po tej klasie i nadpisywac uprawnienia/meotdy ktore chce miec po swojemu.

Ja bardzo lubie DRY i staram sie byc z nim na Ty

A jak stoi do tego Laravel?

Może jestem w błędzie i nie masz powtórzeń w kodzie, ale votery (zakładam, że mówimy o klasach a nie obiektach) dla każdej encji budzą takie podejrzenia. Ty widzisz swój kod i jak mówisz, że nie masz powtórzeń to spoko, mogę spać spokojniej.

przyklady z dokumentacji Symfony wskazuja dosc jasno, ze dla kazdej Entity ma byc oddzielny Voter, co raczej jest dosc logiczne.

Nie zmienia to jednak faktu, że mozna napisac jeden bazowy voter, z ktorego inne w razie potrzeby beda korzystac.

Ja ostatecznie zrobilem jak pisalem na poczatku: mam jeden voter na wszystkie Entity, ktore to voter realizuje ogolne sprawdzanie praw, ktore dla wielu Entity bedzie takie samo. Ten jeden voter rejestruje w services jako wlasnie voter by symfony go ladowalo.
Do tego, jesli jakas Entity bedzie wymagac wlasnych oddzielnych praw, tworze Voter specjalnie dla niej, ale nie rejestruje juz go w services jako entity. Ten jeden glowny Voter sprawdza, czy istnieje voter dla danej entity. Jak nie, to robi swoje ogolne rzeczy, jak tak, to laduje ten specjalny voter dla danej Entity i przekazuje sprawdzanie temu specjalnemu Voter. Dzieki temu mam uniwersalnosc ale i w razie potrzeby specyficznosc i mam DRY - tak wiec spij spokojnie

A jakbyś spróbował ogać to na Interface'ach?

W praktyce, interesuje Cię czy dana encja (czy dowolny inny model - tutaj akurat na plus, bo metody możesz współdzielić o ile implementujesz Interface / extedujesz jakiś base-abstract).

Przeważnie masz dość prosty warunek, taki jak sprawdzanie czy... no nie wiem... chociażby "createdBy" to obecnie zalogowany user, ograć to Interface'em, dać voter do sprawdzania "IS_CREATOR" i weryfikować support dać na wcześniej wspomniany Interface.

Możesz też podbić priorytet przy rejestrowaniu serwisu, w praktyce nie rozwiąże to Twojego problemu, ale tyle o ile (o ile często weryfikujesz ów warunki) przyspieszysz nieco ten proces (nieco - pewnie jakieś atomowe części sekundy ).

Poza tym, w voterze możesz odpalać inne votery Symfony\Component\Security\Core\Authorization\AccessDecisionManagerInterface @security.access.decision_manager - tak jakbyś kiedyś szukał

Jest to tez jakies rozwiazanie. Teraz robie to sprawdzanie w ogolnym voterze. Fakt, mozna przeniesc to do entity implementujacej interfejs. Musze sie z tym przespac


Ale by to zrobic musze mu przekazac te inne votery czyli musze jest stworzyc. Nie widze sensu. Teraz w moim rozwiazaniu tworze obiekt votera jesli taki specyficzny isntieje i odpalam jego sprawdzanie. Nie widze sensu pakowac to jeszcze w ten DecisionManager skoro wszystko mam pod reka

Inaczej nie sprawdzisz (logicznie) warunku, czy user jest np Adminem.

Z poziomu kontrolera, robisz to przeważnie ->isGranted('ROLE_ADMIN'). poza tym, możesz też mieć dynamiczne role, zależne od posiadanych relacji (np user w grupie ma w standardzie rolę ROLE_{NAZWA_GRUPY}) itd. itp. - do bardziej złożonych kwestii.

Ja wiem. Poprostu nie widze sensu w moim ogolnym voter inicjalizowac na nowo ten manager dla danej specyficznej entity podczasy gdy ten specyficzyny voter tak czy siak mam pod reka

Zawsze możesz stworzyć votera, który wywołuje tylko niezbędne votery / obiekty sprawdzające uprawnienia

No wlasnie tak teraz mam