Session handler, Czy opłaca się trzymać osobno zmienne? Opcje

[Prph]

Witam,

W PHP5 zaawansowane programowanie autorzy przedstawili mechanizm obslugi sesji, ktory trzymal zmienne w osobnej tabeli. Dzieki tezmu wydajnosc miala nieco wzrosnac.

Takie rozwiazanie jednak ma pewna wade - zmienne pobierane za z sesji poprzez metody __get i __set, nie zaś $_SESSION['zmienna'];

W chwili obecnie przysparza mi to więcej problemów niż mogłem to sobie wyobrazić.

Jak Wy organizujecie session handlera? Jest sens dzielenia sesji na zmienne i info o sesji?

Pozdrawiam,
Adrian.

[hawk]

@Prph: Teraz sprawa się komplikuje, bo dochodzi jeszcze cała klasa User, a ja generalnie nie lubię klas o nazwie User (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

ad. 1. Pisząc "pusty obiekt" miałem na myśli obiekt klasy User, nie trzymający żadnych informacji oprócz ID usera. Patrząc na konstruktor klasy User, wycofuję to zdanie.

ad. 2. Tak, to nie sesja powinna decydować o tym, skąd wziąć "dane" użytkownika. Ale też nie powinna o tym decydować - o dziwo - klasa User. W twoim przykładzie jest to zaszyte częściowo w klasie sesji (sprawdzanie hasła i logowanie), a częściowo w klasie User (wyciąganie grup).

Teraz kilka słów natury ogólnej:

Klasa sesji, session handler, itd. powinny być minimalistyczne i nie robić nic poza utrzymywaniem i obsługą samej sesji, ponieważ wykorzystywane są często i wszelka dodatkowa funkcjonalność nas ogranicza. Przykładem jest twoja klasa sesji: umieszczając w niej kod sprawdzający poprawność hasła użytkownika pozbawiłeś się możliwości walidacji tego hasła na podstawie np. LDAP. Chcąć użyć tego nieszczęsnego LDAPa będziesz musiał napisać drugą klasę sesji, ze zmienioną funkcją do logowania. I w tym momencie okaże się, że najlepiej wyrzucić logowanie do osobnego obiektu i podmieniać w ramach potrzeb (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Klasy User, jak napisałem, nie lubię. Każda aplikacja może miec specyficzne dane, które związane są z użytkownikiem: e-mail, nr GG, avatar... Wspólnym mianownikiem jest tutaj konieczność uwierzytelniania użytkownika, a zatem login, hasło i - w zależności od przyjętego modelu uwierzytelniania - grupy, role, itd. To nie jest użytkownik! Najlepszym znanym mi słowem jest angielskie Credentials. Ewentualnie token, passport, itd.

Ale umieszczanie w tej klasie funkcjonalności pobierającej listę grup jest złe, ponieważ znowu ograniczamy się do jednego źródła danych. Jeżeli grupy użytkownika też zaczniemy przechowywać na serwerze LDAP, będziemy musieli napisać klasę LDAPUser i używać zamiast zwykłego User.