[PHP] Gültigkeit von Klassen/Variablen über Skriptgrenzen

[FinalFantasy]

Hi,

ich habe mir überlegt, meine ganzen Datenbankaufrufe in eine PHP-Klasse zu packen.

Das hätte unter anderem den Vorteil, dass ich den Datenbankinhalt cachen könnte, und nicht bei jedem Seitenzugriff eine/mehrere echte SQL-Abfragen machen müsste.

Allerdings stellt sich die Frage wie sich Klassen verhalten, wenn sie über mehrere PHP-Skripte verteilt benutzt werden.

Ich erstelle beispielsweise im ersten PHP-Skript index.php die Klasse

$class = new myclass;

durch einen Link kommt wird nun beispielsweise ein anderes skript aufgerufen:

site2.php

In diesem Skript ist jedoch $class nicht mehr verfügbar, oder?

Selbst wenn index.php sich selbst nochmal aufruft ist die alte klasse nicht mehr verfügbar und es wird eine neue Instanz angelegt.

Wie sieht das aus, wenn ich die Klasse im index.php als static anlege, also

static $class = new myclass;

bleibt die Klasse dann erhalten?

Das einzige was mir sonst noch einfallen würde, wäre es, die Klasse in eine Session zu packen. Jedoch befürchte ich, dass die Klasse recht gross werden könnte, weil ja doch einige Daten anfallen (selbst wenn nur häufig benötigte Daten gecacht werden (Zugriffsrechte, Benutzereinstellungen....).

Vorteil dieser Sache wäre halt, dass ich meine SQL-Abfragen gekapselt hätte und nicht über den kompletten Source verteilt hätte. (siehe Thread "Vor und Nachteile von Views") Das mit dem Cachen muss ja nicht unbedingt sein, eine Global gültige Klasse wäre aber trotzdem vorteilhaft.

Was haltet ihr von der Idee? Ist es vielleicht doch performanter jedesmal die Datenbank abzufragen??

[geloescht_JesterDay]

In diesem Skript ist jedoch $class nicht mehr verfügbar, oder?

[...]

Was haltet ihr von der Idee? Ist es vielleicht doch performanter jedesmal die Datenbank abzufragen??

HTML ist "stateless", also jede Anfrage beim Server, und sei es nur um ein Bild für die Seite zu laden, ist eine neue, komplett eigene Anfrage. die einzige Möglichkeit mehrere Anfragen quasi zusammenzufassen ist über Cookies (die Session geht auch nur mit Cookies bzw. indem die SessionID, die ja eigentlich in einem Cookie abgelegt wird, jedesmal mit Übergeben wird).

Nachdem dein Skript abgearbeitet wurde ist es weg. Es bleiben keine Klassen o.ä. im Speicher, was ja auch gut so ist.

Die Session wäre eine Möglichkeit, aber wenn etwas performancelastig ist bei dieser Konstellation, dann ist es die Übertragung der Daten vom Webserver zum Client. Und selbst wenn dieses Abfrageergebnis in einer Session zwischenspeicherst muss ja irgendwas übertragen werden bzw. muss für die Session jedesmal eine Datei angelegt bzw. geöffnet werden. Sessions werden im allgemeinen eher als Performancekiller gesehen (bei jedem Seitenaufruf muss eine Datei gesucht, angelegt/geöffnet und geschrieben/gelesen werden).

Wenn du Angst wegen der Performance hast, dann optimiere lieber dein SQL. Also z.B. kein SELECT * FROM, sondern wirklich nur die Felder, die du brauchst SELECT Feld1, Feld2 FROM. Das spart u.U. schonmal ne Menge Daten, die übertragen werden (und wenn es nur vom DB-Server zum PHP-Interpreter ist).

EDIT:

Das zusammenfassen der Abfragen kann gut sein. Was auf jeden Fall gut ist, ist eine Zwischenschicht zw. deiner Anwendung und der DB. Also das du eine Include Datei machst, in der du DB-Connects, DB-Abfragen u-ä. machst. In deinen Skripten rufst du dann nur deine Methoden auf. Somit bist du von keiner DB abhängig und brauchst um deine Skripte auf eine andere DB umzustellen nur dieses eine Include File auszutauschen.

Das Zusammenfassen der SQL-Texte in einer Datei hab ich auch mal gemacht. Dachte mir es ist besser alles zusammen zu haben, als quer über die Skripte verteilt. Am Ende war es aber viel unübersichtlicher IMHO. Du siehst dir ein Skript durch und um zu sehen, was in dem SQL eigentlich getan wird, musst du erst irgendwo anders das passende SQL suchen. Ich hab das nur einmal gemacht und mach es jetzt wieder "normal".

[kills]

um Objekte/Variablen von einem ins nächste Script zu bekommen hast du nur folgende möglichkeiten:

Sessions

mit serialize() an einen link anhängen

mit serialize() in ein hidden formular field

http://de3.php.net/manual/en/function.serialize.php

[Krain]

Läßt sich das Objekt nicht auch in einer Session speichern? Ich bin der Meinung ich hätte das schonmal so gemacht!? Ich such mal danach.

gruss

markus

[FinalFantasy]

Naja, es ist halt so, dass es etliche Daten gibt, die ich auf jeder Seite brauche. Z.B. Benutzername, persönliche Einstellungen (Skins, Zugriffsrechte...) Von der Performanceseite her habe ich (momentan) noch keine Probleme.

Also ist Cachen zumindest von grösseren Datenmenge eher unrentabel....

Naja, dann werd ich die DB-Actionen wohl in eine Klasse kapseln, ohne dabei zu cachen. Eine einfach Funktionsansammlung ist mir auch irgendwie zu lose.

[kills]

Läßt sich das Objekt nicht auch in einer Session speichern? Ich bin der Meinung ich hätte das schonmal so gemacht!? Ich such mal danach.

gruss

markus

hab ich doch oben geschrieben, das man mit serialize() objekte auch als String übergeben kann....

Naja, es ist halt so, dass es etliche Daten gibt, die ich auf jeder Seite brauche. Z.B. Benutzername, persönliche Einstellungen (Skins, Zugriffsrechte...) Von der Performanceseite her habe ich (momentan) noch keine Probleme.

Also ist Cachen zumindest von grösseren Datenmenge eher unrentabel....

Naja, dann werd ich die DB-Actionen wohl in eine Klasse kapseln, ohne dabei zu cachen. Eine einfach Funktionsansammlung ist mir auch irgendwie zu lose.

Solche Daten kannst du natürlich in der Session mitführen.

mach dir einfach ein array in die session.

z.b.

$_SESSION['user']['id'] = 721;

$_SESSION['user']['password'] = "adfasd" // aber hier am besten eine md5 summe!

$_SESSION['skin']['name'] = "skyblue";

.

.

.

[/PHP]

so fährst du am besten.

ein ganzes objekt da rein zu hängen finde ich übertrieben und bläht die session unnötig auf.

Dann lieber ein SQL doppelt abgeschickt!

Die DB ist auf jeden Fall schneller als die Session.

Gruß,

Markus

[geloescht_JesterDay]

$_SESSION['user']['id'] = 721;

$_SESSION['user']['password'] = "adfasd" // aber hier am besten eine md5 summe!

.

.

.

[/PHP]

Das Passwort würde ich garnicht speichern bzw. cachen. Das PW ist als md5 in der DB gespeichert. Bei der Anmeldung wird der Benutzername und der md5-Hash des

eingegebenen PW überprüft und wenn es passt wird die User-ID gefüllt. Damit hat man alles, um den User eindeutig zu identifizieren.

[PHP]
$name = $_POST['UNAME'];
$pw = $_POST['pw'];
$sqltext = "SELECT UID FROM USER WHERE UNAME = '$name' AND UPASS = 'md5($pw)'";
.
.
.
$_SESSION['user']['id'] = $row[0];