session manager, kluts kwijt
Waar gaat het over?
Als ik vroeger iets wilde opslaan in de $_SESSION array, dan gebruikte ik daar een "SessionManager" class voor. Als ik iets in de $_SESSION array wilde zetten, dan deed ik dat als volgt:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
$sm = $container->get('session_manager');
$sm->set('user', 'Ozzie');
// ergens anders de waarde ophalen:
echo 'hallo ' . $sm->get('user');
?>
$sm = $container->get('session_manager');
$sm->set('user', 'Ozzie');
// ergens anders de waarde ophalen:
echo 'hallo ' . $sm->get('user');
?>
Nu werd hier op het forum gezegd dat dit geen flexibele oplossing is. Stel dat ik voortaan mijn session data niet meer op wil slaan in de $_SESSION array maar in de database, dan zou dat met mijn oplossing erg lastig worden.
De betere oplossing was, volgens enkele leden op het forum, deze:
We stoppen de key en value niet meer rechtstreeks in de SessionManager, maar we stoppen ze eerst in een apart Session object. Daarna geven we dat Session object door aan de SessionManager en de SessionManager slaat de data op in de $_SESSION array, of in de database (afhankelijk van het type SessionManager).
Precies hetzelfde voorbeeld als hierboven, maar nu met de opzet die enkele leden hier op het forum aanraden:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
$sm = $container->get('session_manager');
$session = new Session();
$session->setId('user');
$session->setValue('Ozzie');
$sm->update($session);
// ergens anders de waarde ophalen:
$session = $sm->get('user');
echo 'hallo ' . $session->getValue();
?>
$sm = $container->get('session_manager');
$session = new Session();
$session->setId('user');
$session->setValue('Ozzie');
$sm->update($session);
// ergens anders de waarde ophalen:
$session = $sm->get('user');
echo 'hallo ' . $session->getValue();
?>
Zoals je ziet vergt deze methode meer typwerk. Maar goed, als het een meerwaarde heeft dan valt daar iets voor te zeggen. Alleen mijn vraag is wat deze meerwaarde nu eigenlijk is.
Het idee van mensen die voorstander zijn van deze laatste methode, is dat je enkel door de SessionManager class te wijzigen, je al je sessie data in één keer ergens anders kunt opslaan. Bijvoorbeeld, door in plaats van een SessionManager te gebruiken die alles in de $_SESSION array opslaat, gebruik je een SessionManager die alles in de database opslaat, en voila... alle session data wordt in de database opgeslagen.
Prima, goed idee! Klinkt goed.
Maar nu mijn kritische noot. Waarom zou datzelfde niet op "mijn" manier kunnen? Als je de SessionManager class in het eerste voorbeeld wijzigt door een SessionManager class die de sessie data in een database kan opslaan, dan heb je toch precies hetzelfde effect? (Met een interface dwing je af dat een SessionManager altijd dezelfde methods heeft.)
De Session class in het 2e voorbeeld heeft de volgende methods: getId(), setId(), getValue() en setValue().
Dus een object met 4 methodes enkel om een ID => value paar op te slaan. Waarom? Het enige wat de SessionManager hoeft te weten is: WAT moet ik opslaan (de value) en onder welke ID. Waarom gaan we rondom deze basale informatie dan een aparte class bouwen? Waarom zeggen we niet rechtstreeks tegen de SessionManager, dit is de ID en dit is de value. Waarom moet daar een hele class of container omheen worden gebouwd die we vervolgens doorgeven aan de SessionManager, en waar de SessionManager vervolgens de ID en value weer uithaalt? Waarom niet direct de ID en value aan de SessionManager doorgeven?
Wie kan het mij uitleggen? Ik zie blijkbaar iets over het hoofd, maar ik zou zo graag weten wat...
Wie helpt me uit de brand?
Gewijzigd op 02/03/2014 15:51:31 door Ozzie PHP
Waarom een object? Tja, ik gebruik tegenwoordig steeds meer principes van Domain Driven Development. Daarin werk je eigenlijk altijd met objecten (Value Objects of Date Transfer Objects) om data van de ene laag (de usage laag) naar de andere (de implementatie laag) te verplaatsen.
Oké, maar dat heb exact zo ik overgenomen uit jouw eigen voorbeeld:
http://www.phphulp.nl/php/forum/topic/request-class/88420/4/#635463
>> Waarom een object? Tja, ik gebruik tegenwoordig steeds meer principes van Domain Driven Development. Daarin werk je eigenlijk altijd met objecten (Value Objects of Date Transfer Objects) om data van de ene laag (de usage laag) naar de andere (de implementatie laag) te verplaatsen.
Afgezien van het feit dat jij dan blijkbaar steeds vaker voor een bepaalde implementatie kiest, wat is nu daadwerkelijk in deze situtie de toegevoegde waarde van zo'n object? Het gaat hier simpelweg om een ID => value paar. Is het echt nodig om daar een complete class omheen te bouwen? Als je een array vult met waardes, dan ga toch ook niet van ieder element eerst een object maken, en dat object vervolgens toevoegen aan de array? Waarom in dit geval die extra abstractielaag?
De reden voor de opzet met losse Session objecten was volgens een aantal van jullie dat het meer flexibel zou zijn dan "mijn" opzet, waarbij geen losse Session objecten worden gebruikt. In mijn opzet zou het niet mogelijk zijn, of in ieder geval moeilijker, om te wisselen van opslagmedium. Met mijn variant zou je niet zomaar alle data die je nu in de $_SESSION array opslaat, kunnen opslaan in de database. Dat zou met jouw opzet makkelijker gaan. Dat ben je toch wel met me eens?
Nu is mijn vraag... waarom biedt het gebruik losse objecten meerwaarde? Als ik 2 verschillende SessionManagers heb, 1 voor de database en 1 voor de $_SESSION array, dan kunnen deze beide SessionManagers toch een get method hebben, waarbij de 1e variant de data uit de databse haalt en de 2e variant de data uit de $_SESSION array? In de opzet met losse Session objecten heb je zelfs een aparte update/save method nodig. Als je zonder losse objecten werkt, kun je de data rechtstreeks updaten op het moment dat je de value wijzigt, en heb je dus geen extra update method nodig. Enkel een setValue method die in het eerste geval de data in de database wijzigt en in het 2e geval de data in de $_SESSION array.
Ik ben nu erg benieuwd waar de concrete meerwaarde zit in de opzet met losse Session objecten. Dit was dé manier volgens een aantal van jullie, dus dan lijkt het me ook dat er een essentieel voordeel aan moet zitten. Maar ik zie het (nog) niet.
Iemand?
Offtopic:
Wouter J op 02/03/2014 16:08:06:
... en nog mooier: gebruik een factory: Session::create('user', 'Ozzie')
Waarom zou je een factory willen gebruiken ipv $session = new Session('user', 'Ozzie')? Dit soort dingen doe je toch altijd via de constructor?