klasa logowanie - gdzie sprawdzac zmienne sesyjne Opcje

[become]

Witam.

Jako ze zaczalem uczyc sie OOP chcialbym sie dowiedziec, gdzie umiescic sprawdzanie czy user jest zalogowany ?
Chodzi o to, ze chce informacje o tym czy jest zalogowany trzymac w sesji. I teraz jak zorganizowac klase logowanie ?
Chcialbym przy kazdym przeladowaniu strony sprawdzic, czy istnijeje zmienna sesyjna np. 'userlogin' i na podstawie jej wartosci zalogowac go. Czy calosc operacji zrobic w klasie, czy np. gdzies w kodzie najpierw sprawdzic czy zmienna sesyjna istnieje i dopiero pozniej ewentualnie utworzyc klase Logowanie(), czy raczej przy kazdym wywolaniu strony tworzyc klase Logowanie a w środku niej sprawdzac czy user jest zalogowany ?

[Cysiaczek]

@Sedziwoj - jasne - każdy pisze jak mu wygodniej, byle miało to ręce i nogi (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Z niektórymi rzeczami jednak nie do końca się zgadzam

masz zawsze jednego User'a w systemie na raz (taka właściwość skryptów po stronie serwera) więc tworzenie kolekcji jest bezcelowe.

Obiekt User potraktowany jako obiekt danych może zostać wykorzystany w różnych częściach systemu.
1. Sesja użytkownika
2. Zakładanie / modyfikacja danych użytkownika
3. Listowanie danych o wielu użytkownikach (np w panelu admina)

W punkcie #3 kolekcja jest jak najbardziej użyteczna. Jej przydatność widać też tam, gdzie wykonujemy wiele różnych operacji na obiekcie User - obiekt trzeba pozyskać, sprawdzić jego stan, a w razie konieczności zapisać. Jeśli wszystko to będzie agregował obiekt User, to jego funkcjonalność strasznie się rozrośnie i chcąc nie chcąc - stanie się on zarządcą samego siebie uzależnionym od wielu innych obiektów i wyposazonym w wiele okazjonalnych metod np. User::getPosts(). Automatycznie przenośność kodu spada do zera.

Pozdrawiam.

[Sedziwoj]

@Sedziwoj - jasne - każdy pisze jak mu wygodniej, byle miało to ręce i nogi (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Z niektórymi rzeczami jednak nie do końca się zgadzam
Obiekt User potraktowany jako obiekt danych może zostać wykorzystany w różnych częściach systemu.
1. Sesja użytkownika
2. Zakładanie / modyfikacja danych użytkownika
3. Listowanie danych o wielu użytkownikach (np w panelu admina)
W punkcie #3 kolekcja jest jak najbardziej użyteczna. Jej przydatność widać też tam, gdzie wykonujemy wiele różnych operacji na obiekcie User - obiekt trzeba pozyskać, sprawdzić jego stan, a w razie konieczności zapisać. Jeśli wszystko to będzie agregował obiekt User, to jego funkcjonalność strasznie się rozrośnie i chcąc nie chcąc - stanie się on zarządcą samego siebie uzależnionym od wielu innych obiektów i wyposazonym w wiele okazjonalnych metod np. User::getPosts(). Automatycznie przenośność kodu spada do zera.
Pozdrawiam.

A co to ma wspólnego z przechowywaniem kolekcji obiektów User w obiekcie do autoryzacji?

@NoiseMc
Opracowałem coś w sumie podobnego, tylko że sposób autoryzacji jest ustawiany w configu (z prostego powodu, w zależności od tego czy to jest developerska czy nie inaczej jest sprawdzana...) do tego nie ma u mnie takiego czegoś jak użytkownik, jest login i hasło, więc nie utworzyłem tego obiektu, zbędny jest (przerost formy nad treścią by był). No i jest o wiele bardziej rozbudowane sprawdzanie dostępu... ale to już nie ten temat ;]