[PHP & OOP] Objecten bewaren?

[verytallman]

Ik kan al aardig Java proggen, maar nu wou ik eens OOP gaan proggen in PHP.....wat een gedoe man!

Anyway, ik loop nu tegen een probleem aan. Klopt het dat als ik objecten aanmaak in bijvoorbeeld index.php, dat die objecten weg zijn zodra naar een andere pagina ga(op die website, zeg nieuws.php)
Kort gezegt; objecten bestaan alleen voor de duur dat je op de pagina bent waar je ze gemaakt hebt?

Klopt dit of is het toch mogelijk ?

[MetalfanBlackness]

http://nl2.php.net/manual/en/language.oop.serialization.php

[verytallman]

Ja misschien iets te snel een topic geopend....maar objecten in sessies hebben ook nadelen zit ik alweer te lezen.

Dit is wel balen en ik begin ook steeds minder te geloven in OOP met PHP

[Brakkie]

Memcache is dan misschien een betere oplossing om je objecten te cachen.

[farlane]

verytallman schreef op donderdag 24 november 2005 @ 07:27:
Klopt het dat als ik objecten aanmaak in bijvoorbeeld index.php, dat die objecten weg zijn zodra naar een andere pagina ga(op die website, zeg nieuws.php)
Kort gezegt; objecten bestaan alleen voor de duur dat je op de pagina bent waar je ze gemaakt hebt?

Lijkt me een gevolg van het stateless HTTP verhaal.

[Michali]

Klopt helemaal. Wat je wel kunt doen is een object in je sessie zetten, als zou ik dat niet aanraden. Wat ik zelf altijd doe is gewoon die objecten aanmaken (en uit de database trekken) die ik nodig heb voor de betreffende actie.

[Genoil]

Ik gebruik Propel, een persistent or/m laag. Of je nou objecten serialized in een sessie of opslaat in een database maakt natuurlijk niet zoveel uit, behalve dat het laatste wat praktischer is. Ik gebruik Propel echter doorgaans alleen als Model layer, maar je zou er in principe een Controller-achtig object in kunnen oplsaan zodat je de state kunt bewaren tussen 2 requests.

[sariel]

Michali schreef op donderdag 24 november 2005 @ 08:51:
Klopt helemaal. Wat je wel kunt doen is een object in je sessie zetten, als zou ik dat niet aanraden. Wat ik zelf altijd doe is gewoon die objecten aanmaken (en uit de database trekken) die ik nodig heb voor de betreffende actie.

En wat is er mis met sessies? Ik gebruik eigenlijk altijd sessies, en dat gaat tot nu toe prima. Als je alles steeds uit database moet trekken, zit je met het probleem dat je steeds weer die database verbinding moet gebruiken om alle data op te halen, en dat kan een aanzienlijke vertraging opleveren van de performance van je website.
Als je alles in sessie houdt, dan heb je meteen toegang tot je data (blijft nl. in geheugen van webserver), en is er geen vertraging. De enige reden die ik mij kan verzinnen waarom je dit doet, is omdat je een stapeltje webservers hebt, met een database backend. Dan zou het handig kunnen zijn, maar als je een share maakt waar beide webservers hun sessie info dumpen, dan is dat ook nog sneller....

[Genoil]

Het grootste nadeel vind ik dat je je classes moet 'requiren' voordat je de sessie start. Verder kost deserializen natuurlijk ook gewoon tijd. In PHP4 worden references ook nog eens gesloopt.

[Sybr_E-N]

By the way er is nogal een groot verschil tussen het OOP model in PHP4 en PHP5, aangezien je niet verteld in welke versie aan het programmeren bent. (in PHP5 is een beter OOP model aanwezig voor de verschillen tussen de versies kun je terug op deze en deze pagina.)

[Verwijderd]

Hierboven zag ik de term 'Stateless HTTP', en dit is eigenlijk precies wat hier van toepassing is. Java heeft voor en nadelen, PHP heeft voor en nadelen. Je moet niet teveel naar Java kijken bij het bouwen in PHP. Ik noem maar een voorbeeld: een gebruiker vind een subpagina van jouw page op google. Hij klikt direct door naar deze page, maar guess what, de objecten zijn niet geinitialeerd.

Mijn voorkeur gaat er altijd naar uit gewoon aan het begin van de pagina's de benodigde objecten aan te maken. Als je pagina echt zoveel bezoekers heeft dat dit performence-problemen opleverd, dan kun je wel een bedrijf inhuren die voor je een nieuwe site bouwt

[PrisonerOfPain]

Genoil schreef op donderdag 24 november 2005 @ 09:16:
Het grootste nadeel vind ik dat je je classes moet 'requiren' voordat je de sessie start. Verder kost deserializen natuurlijk ook gewoon tijd.

In PHP5 heb je __autoload() en je kunt eventueel nog unserialize_callback_func aanpassen met ini_set. Dus dat zal niet zo'n groot probleem op moeten leveren.

[Genoil]

PrisonerOfPain schreef op donderdag 24 november 2005 @ 14:51:
[...]

In PHP5 heb je __autoload() en je kunt eventueel nog unserialize_callback_func aanpassen met ini_set. Dus dat zal niet zo'n groot probleem op moeten leveren.

dat __autoload is idd erg handig! jammer dat ik nu net bezig ben m'n class lib cross-php4/5 te maken

[Michali]

sariel schreef op donderdag 24 november 2005 @ 09:11:
[...]


En wat is er mis met sessies? Ik gebruik eigenlijk altijd sessies, en dat gaat tot nu toe prima. Als je alles steeds uit database moet trekken, zit je met het probleem dat je steeds weer die database verbinding moet gebruiken om alle data op te halen, en dat kan een aanzienlijke vertraging opleveren van de performance van je website.
Als je alles in sessie houdt, dan heb je meteen toegang tot je data (blijft nl. in geheugen van webserver), en is er geen vertraging. De enige reden die ik mij kan verzinnen waarom je dit doet, is omdat je een stapeltje webservers hebt, met een database backend. Dan zou het handig kunnen zijn, maar als je een share maakt waar beide webservers hun sessie info dumpen, dan is dat ook nog sneller....

Dat doe ik omdat ik zeker wil weten dat de data nog bestaat in de database. Bovendien weet ik niet zeker of ik bepaalde data nodig heb op een andere pagina en om het nou allemaal maar in de sessie te gooien lijkt me ook niet echt efficient, dat serializen is ook niet echt snel denk ik. Bovendien is de performance nu prima, krijg ik wel problemen, dan ga ik gewoon profilen en de oorzaak van de performance hit aanpakken. Als dat idd het data uit de db trekken is dan zoek ik daar een oplossing voor. Over het algemeen is de tijd die ik daarmee kwijt ben marginaal vergeleken bij het includen en parsen van bestanden (maar dat is ook goed te optimaliseren met zo'n cacher).