Po zrobieniu klasy User i UserManager (poprzedni post) przyszedl czas na stworzenie komponentu odpowiedzialnego za Logowanie i sprawdzanie Sesji. Z tego co juz zrozumialem klasy User i UserManager nie powinny miec z tym nic wspolnego, zakladam zatem ze potrzebuje klase Login badz jakas inna ktora bedzie te funkcje posiadac. Do tego przy kazdym przeladowaniu strony potrzebuje cos co sprawdza czy sesja juz istnieje, czy to tez jest zadanie dla loginu czy kolejnego osobnego komponentu ? Lopatologiczne wyjasnienia mile widziane.

Nie. Login to czynność a nie klasa. Potrzebujesz klasy w stylu SessionManagement (nazwij jak chcesz, aby nie Login), która będzie miała funkcjonalność logowania.

Moje pytanie w moim temacie:


Odpowiedź użytkownika @smentek



Może Ci się przyda

Dobrze jest zrozumieć ideę autoryzacji i autentykacji.

Możesz to zrobić na bardzo wiele sposobów. Najpierw przemyśl czy i jak system będzie rozbudowywany. Mógłbyś zrobić klasę ogólną System, która byłaby odpowiedzialna za spr. sesji i zasobów, które ta sesja posiada.

[PHP] pobierz, plaintext 
// uzytkownik wywołał akcję  $objSystemController->login();
public function login()
{
 strHashResourceId = SessionManager::getUserHash();
 System::isLogged( $strHashResourceId );
}
[PHP] pobierz, plaintext 

Przydałoby Ci się to w sytuacji gdzie zalogowany mógłby być nie tylko użytkownik ale np. zewnętrzny system. W klasie System chciałbyś wtedy zablokować korzystanie z systemu innym użytkownikom. Jeśli chcesz w ten sposób rozwijać projekt dobrze odseparować logikę zarządzania sesją właśnie do jakiejś osobnej klasy (System lub SessionLogger).

Inny patent to ustalenie w jakim stanie (userIsLogged, extSystemIsLogged, awaria, aktualizacja [...] ) znajduje się aplikacja. Tutaj też mógłbyś użyć klasy System. Wtedy w tejże klasie sprawdzałbyś stan całej aplikacji i udostepniał np. tylko niektóre zasoby jeśli system miałby jakąś awarie, ma to swoje wady/zalety/zależności.

Ale na początek zrobiłbym spr. sesji w najprostszy sposób jaki Ci odpowiada. Potem mógłbyś zmienić całość pod kątem pełniejszego zarządzania procesem logowania, jeśli uznasz że jest Ci to potrzebne.
Pamietaj, że rozbijanie odpowiedzialności ma swoje implikacje w rozrastaniu się kodu. Dlatego trzeba zawsze myśleć o tym co jest potrzebne na teraz, na za miesiąc i potem za rok czy dwa (czego nie jesteś w stanie już tak prosto określić). Więc trzymaj się prostoty i zbytnio nie uelastyczniaj aplikacji na początku, bo można się zamotać. Aplikacje można doskonalić w nieskończoność.

Moim zdaniem mógłbyś zrobić to w taki sposób:

[PHP] pobierz, plaintext 
public function login() {
	$sessionManager = System::getInstance()->getSessionManager();
 
	if($sessionManager['user']) {
		return 'zalogowany'; //nic nie trzeba robić
	}
 
	else {
		$login = $_POST['login'];       // nie traktuj tych dwóch linijek całkiem poważnie. To powinno być zrealizowane w inny sposób
		$password = $_POST['password']; // np w taki: $this->getParam('login');  gdzie getParam filtruje dane itp.
 
		$userManager = new UserManager();
		$user = $userManager->login($login, $password)
 
		if($user) {  // to lepiej za pomocą wyjątków try { } catch(UserNotFoundException $e) {} } 
			$sessionManager['user'] = serialize($user);   //zalogowany! do sesji został dodany obiekt użytkownika
		}
	}
 
}
 
public function showLogged() {
	$sessionManager = System::getInstance()->getSessionManager();
	print_r($sessionManager['user']);
}
[PHP] pobierz, plaintext 

a teraz opis
klasa System jest singletonem (zobacz na wiki).
Przechowuje wszystkie 'kluczowe' dla aplikacji obiekty. Typu np SessionManager, może DBManager?
System::getInstance()->getSessionManager() zwraca obiekt SessionManagera który implementuje interfejs ArrayAccess dlatego można używać cudów jak $sManager['user'], ale powinna być też możliwość $sManager->get($user); itp

$sessionManager['user'] = serialize($user) - czyli przypisujesz do klucza sesji 'user' zserializowany obiekt użytkownika.

i voila!

Jeżeli nie masz dostępu do głównych obiektów inaczej niż przez kontener(w dodatku Singleton) to coś z Twoją aplikacją jest chyba nie tak? a może się mylę?

Klasa System nie musi być singletonem. Może spełniać rolę fasady. Dostęp do SessionManager może być również bezpośredni jeśli tak sobie to założysz. Ja wykorzystuje klasę System do paru podstawowych ogólnych czynności na wjazd i wyjazd z programu. Inny przykład $objSystem->setDeathView() co powoduje wykrozystanie klasy ustawiającej barwy strony na szare ($objColorizer) jak ktoś sławny kopyrtnie . Jeśli ta klasa zacznie mi się rozrastać to powyrzucam części kodów do innych, ale narazie jakoś daje radę istnieć.

z mojego kodu nic takiego przecież nie wynika.
To jak sobie zaimplementujesz zależy od Ciebie.
Ta metoda:
System::getInstance()->getDatabaseManager();
może wyglądać chociażby tak

[PHP] pobierz, plaintext 
{
 return DatabaseManager::getInstance();    // LUB return $this->databaseManager;       - DBM nie musi być singletonem.
}
[PHP] pobierz, plaintext 

albo

[PHP] pobierz, plaintext 
{
 return $this->register['DatabaseManager'];
}
[PHP] pobierz, plaintext 

albo w ogóle nie mieć metody getDatabaseManager i takie obiekty zaprojektować jako singletony i 'brać je': DatabaseManager::getInstance()

to zależy od Ciebie jak to zaimplementujesz.

Ale tych singletonów Ci się narobi w kodzie:)
Chcesz klasę do obsługi dwóch akcji: logowania i sprawdzania czy ktoś jest zalogowany . Do tego dodaj sobie jeszcze dwie akcje: wylogowanie i zwracanie zalogowanego użytkownika, bo jest to wszystko logicznie ze sobą powiązane. Jednym słowem potrzebujesz klasy do obsługi autoryzacji:

[PHP] pobierz, plaintext 
class Authorization {
public function login($login, $password);
public function logout();
public function isLogged(); //zwraca true, jeżeli jest ktoś zalogowany, false w innym wypadku
public function getLoggedUser(); //zwraca zalogowanego użytkownika
}
[PHP] pobierz, plaintext 

Do pełnej funkcjonalności są ci potrzebne jeszcze klasy do obsługi sesji, opcjonalnie cookie i do obsługi połączeń z bazą.
Żadna z tych klas nie powinna być singletonem, ponieważ nie ma ku temu żadnych powodów.
Klasy do obsługi sesji i ciasteczek i tak korzystają z globalnych tablic, więc po co ci implementowanie ich jako singletonów? Po to, żeby było:

[PHP] pobierz, plaintext 
Session::getInstance()->method();
[PHP] pobierz, plaintext 

Zamiast:

[PHP] pobierz, plaintext 
$session = new Session();
$session->method();
[PHP] pobierz, plaintext 

A co do połączeń z bazą, to już tym bardziej jest to nie logiczne, bo co w przypadku, gdy będziesz obsługiwał x połączeń z różnymi bazami?
Sama aplikacja (czy też system, czy jak to tam nazwiesz) również nie ma żadnego większego powodu, żeby była singletonem, bo po co? Zastosowanie wzorca ma sens, wtedy i tylko wtedy, gdy ma sens:) Jeżeli nie ma żadnego logicznego uzasadnienia do używania wzorca, to się tego nie robi. Nawet jeżeli tworzysz zazwyczaj (albo nawet zawsze) tylko jeden obiekt danej klasy, to nie jest to żadnym uzasadnieniem do stosowania singletonu. Singleton stosujesz wtedy, gdy nie może być dwóch obiektów tego samego typu.