Hi,
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.
ich meinte das anders. Mir gings ums Performance und um die Pflege des Datenzugriffs. Koennen die RDBMSe stored procedures, so pflege ich ein CRUDL-Rudel davon, ansonsten habe ich ein Rudel Funktionen in der Sprache der serverseitigen Logik.
Ausserdem gibt es doch oft fuer jede Datenbanktabelle verschiedene Einstellungen, baust Du fuer diese Datenbanktabellen verschiedene Klassen? (Habe ich vor vielen Jahren auch _einmal_ gemacht. :-)
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?
Sicherheit ist schon gegeben. :-)
Was machst Du aber, wenn Du auf nicht mehr aktuellen daten sitzt? Auch mit der referentiellen Integritaet (und anderen Integritaeten und Einstellungen) koennte es hart werden. :-)
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.
Wuerg. :-)
Wie seht Ihr das, spricht etwas gegen die zuletzt genannte Vorgehensweise?
Deren (unnoetige?) Komplexitaet spricht m.E. dagegen.
Gruss,
Ludger