Door
Ozzie PHP
op 27-02-2014 00:18
gewijzigd op 27-02-2014 00:20
3.276 views
Ola,
Ik ben benieuwd hoe de meesten van jullie omgaan met gegevens uit de $_SESSION array.
Om deze gegevens te gebruiken, stop je ze vaak in een session(handler) class. Nu kun je hier op 2 manieren mee omgaan. Ik vraag me af hoe de meesten van jullie dat doen.
Manier 1:
Je hebt een session class en daar stop je de $_SESSION data in, bijv. $session = new Session($_SESSION). In de constructor zeg je dan $this->session_data = $session_data. Op het moment dat je iets uit de sessie wil halen doe je $session->get('foo'). Je spreekt dan dus de class property (de $session_data array) aan.
Manier 2:
Je maakt van iedere element in de $_SESSION array een apart object. Al deze objecten laad je vervolgens in in een session handler. Als je nu data wil ophalen, dan moet je dus eerst een apart session object ophalen $foo = $session_handler->get('foo'). Nu hebben we dus een object te pakken. Vervolgens halen we daar de value uit $foo->getValue(). Of, gewoon in 1x $foo = $session_handler->get('foo')->getValue().
Ik wil graag actuele meningen horen. Jouw mening ken ik, maar wellicht zijn er nog meer mensen met een mening. Ik ben ook vooral benieuwd of er überhaupt mensen zijn die voor manier 1 kiezen. Maar bedankt voor de doorverwijzingen.
Waarom zou je een class om $_SESSION heen bouwen? Wat heeft dat voor nut?
Of je nu $session->get('iets') doet of je doet $_SESSION['iets']. Het maakt werkelijk geen enkel verschil.
Maar dat is wel jouw "manier 1" die je beschrijft. Zelfde principe geldt ook voor jouw "Manier 2". Waarom denk je dat dit "goed" zou zijn?
Het is overigens wel goed om een Session class te maken, maar ik vraag me af of je uberhaupt wel het idee er achter weet. Of dat je maar ergens iets hebt gehoord/gelezen over zoiets en het maar klakkeloos aan neemt en wil gaan implementeren.
Als je gebruikt maakt van een session(manager) class dan ben je bezig met OOP. Als je rechtstreeks de globals gaat aanpassen dan niet. Maar ik ben benieuwd naar wat jij bedoelde, en hoe jij het zelf doet.
Bezig zijn met OOP hoeft natuurlijk niet te betekenen dat het ook automatisch goed is.
In dit geval is $_SESSION inderdaad een global. En globlas wil je vaak mijden. Maar vergeet niet dat $_SESSION in zekere zin een ander soort global is. Het hoort namelijk bij PHP. Dus iedereen die PHP draait heeft altijd $_SESSION tot zijn beschikking. Dit hoeft dus niet perse slecht te zijn als jij alleen maar $_SESSIONs uitleest in je controller en daar voldoende aan hebt. Ik zou dan ook zeker geen moeite steken in het maken van een "wrapper" class die eigenlijk precies het zelfde kan/doet.
De rede dat je een Session class maakt is omdat je niet alleen sessions wilt ondersteunen zoals je die kent van $_SESSION. Maar het kan bijvoorbeeld ook zijn dat je juist net iets anders wil. Dat je je sessions bijvoorbeeld wilt opslaan in een database, of in een file, of als cookie, of in iets als Redis of alleen in memory. Noem maar op.
Het enige wat jij als gebruiker van die Session class wilt doen is aangeven in een config bestand wat voor soort Session je wilt gebruiken en daarvoor nog de nodige attributen bij configureren.
Session opslaan in een file, geef dan een besstandslocatie en naam mee. Wordt het Redis, dan een database naam etc.
Daar bij komt kijken dat de wat betere Session classes ook vaak dingen doen tegen session hijacking. Dit en nog veel andere dingen kan je dus meenemen in een Session class en dan heb je er ook echt iets aan.
Kijk juist ook vooral naar al bestaande classes in dit soort gevallen. Die kunnen je op ideeen brengen van wat je er allemaal mee zou kunnen doen.
En als jij het hebt over een session class voor de global $_SESSION, werk jij dan met 1 class waarmee je als het ware de $_SESSION array kan bewerken? Of maak jij van ieder session element 1 class, en gebruik je een session manager om die afzonderlijke classes te "bedienen"?
