Hallo,
Eine SQL-Klasse in der Session zu speichern.. ist das
vollkommener Schwachsinn oder Gang und Gebe?
vermutlich ist das aeusserst ungewoehnlich.
Was ist uebrigens genau eine "SQL-Klasse"?
Also ich habe mir da so eine Art Schablone für Datenbankzugriffe
und -Aktionen gebastelt. Und die (My)SQL-Klasse leitet sich von
einer Solchen ab. Die Schablone ihrerseits liegt hierarchisch
gesehen wiederum einer abstrakten Klasse zugrunde, welche die
eigentlichen 'Mindest-Anforderungen' für eine im System als gültig
anerkannte Datenbank-Klasse bestimmt. Jeder Datenbanktyp hat
dementsprechend eine eigene Implementation dieser abstracten
Datenbankklasse (MySQL,Oracle,Sybase..).
Somit ist u.a. gewährleistet, dass zB erfolgsrelevante Parameter
gesetzt werden (müssen) - wie zB die Zugangsdaten - oder auch
Grund-Methoden implementiert werden (müssen) - wie zB die Iteration
eines Resultsets.
Nun kommt noch hinzu, dass der größte Teil der DB-Daten (Resultsets,
Anzahl Einträge,etc.) gecached wird. Derzeit geschieht das vollkommen
automatisch (dank der DBClass) über die Membervariablen (Arrays) der
DB-Klasse. Somit wird bei jedem Retrieve vorerst geprüft, ob die Daten
evtl. bereits im Cache vorliegen und ggfs. werden die gewünschten
Daten aus dem Cache geladen. Eine Haltbarkeits-Zeit bestimmt wie lange
ein Object im Cache gespeichert werden darf.
So, und angesichts dieser Tatsachen, erscheint es mir sehr abwegig,
diese Klasse nicht sitzungs-persistent zu cachen, da auf diese Art
und Weise gut >paar Dutzend DB-Anfragen entfallen würden.
Du hast einen objektorientierten Datenzugriff entwickelt, also
bspw. kommt ein parametrisiertes Tabellenobjekt hoch und Du laesst
bspw. die "LIST"-Methode ausfuehren?
Die Darstellungsweise spielt auf dieser Schicht noch kein große
Rolle. Das wird später von GUI-Klassen und über Templates geregelt.
Die DB-Klasse sorgt an dieser Stelle zB dafür, dass überhaupt Daten
für eine Liste existieren, ferner auch solch Logiken wie zB das
Auslesen der Daten seitenweise oder aber das Abfangen von Zugriffen,
deren Besitzer keine Rechte für eine derartige Aktion besitzt.
Relationaler Datenzugriff und Objektorientiertheit beissen sich
meines Erachtens. Auch mit der Performance siehts oft nicht so toll
aus. Also mache schreibe ich _nie_ objektorientierten Datenzugriff.
Also ich habe bisher noch keinen Bottleneck spüren müssen. Ich hoffe
auch mal, dass sich da nicht viel ändern wird. M.M.n. ist PHP eine
recht flotte Sprache.
Aber Deine Herangehensweise ist interessant. (Nur das mit der Sessionspeicherung
ist absolut ungewoehnlich.)
Ja, es kam mir selber ja auch komisch vor. Daher auch mein Posting hier ;)
Die größten Bedenken hatte/habe ich eigentlich hinsichtlich der Sicherheit
bzw. dem Auslesen der Session durch Dritte. Sind denn PHP-Sessions allgem.
sicher? Oder kann da jemand mit einiger Mühe theoretisch die Inhalte derer
auslesen?
Gerade ist mir in den Sinn gekommen, die SQL-Klasse evtl. einfach vor jedem
Page-Refresh, oder auch nach relevanten Methodenaufrufen, zu serialisieren
und dann als XML-Datei zu persistieren (gibt's da was Hauseigenes von PHP?).
Und dann nach jedem Refresh die Datei/das Object wieder zu deserialiseren
und anschließend in den Anwendungsscope zu packen.
Das wäre doch eingentlich eine vernünftige Lösung.
Wie seht Ihr das, spricht etwas gegen die zuletzt genannte Vorgehensweise?
Besten Dank für Antworten.
Grüße aus Berlin
Patrik