[php] DB-Zugriff bei OO in php4

[Lutz Zetzsche]

Hi Henning,

Am Montag, 12. Dezember 2005 14:37 schrieb Henning Heil:
> gut. Ich habe schon einiges von Deinen Informationen gelesen, bei Leibe
> aber leider noch nicht alles. Ich werde mal etwas konkreter
>
> hier mal das ursprüngliche und aktuelle Datenmodell:
> http://fastview.motorcityone.com/?uid=63
> und ein wenig neuer(er) code: http://nopaste.php-q.net/177931

ok, also bildet die Klasse im Prinzip eine Datenbanktabelle ab. Dann sehe ich 
schon klarer. :-) Dann kann ich auch einen Vorschlag für die Auflösung des 
logischen Widerspruchs machen, den ich darin sehe, daß man fast alle 
Objekteigenschaften einerseits über den Konstruktor und die set-Funktionen 
sowie andererseits über die Funktion readWishlist() füllen kann. Durch diese 
zwei Wege, die Objekteigenschaften zu initialisieren und nachträglich zu 
ändern bzw. zu überschreiben, besteht die Gefahr, daß die Daten im Objekt 
inkonsistent werden, auch in Hinblick auf die Datenbank.

In Hinblick auf die Datenbank gibt es ja nur zwei Fälle: neue Wunschliste 
anlegen, bestehende Wunschliste einlesen. Daraus folgt, daß der Konstruktor 
für einen neuen Datensatz nur die Werte Status, Name und Passwort akzeptieren 
darf und für einen bestehenden Datensatz nur die UID der Wunschliste aus der 
Datenbank.
Wird eine neue Wunschliste angelegt, ermittelst Du vor dem INSERT-Befehl halt 
kurz die zu vergebende ID aus der Datenbank und speicherst diese nach dem 
Absetzen des INSERT-Befehls auch direkt im Objekt ab ($S_wishlistUID).
Wenn Du eine bestehende Wunschliste einlesen willst, liest Du über die 
übergebene ID den entsprechenden Datensatz mit readWishlist() in das Objekt 
ein. Name und Passwort können dann über die set-Methoden geändert und mit 
saveWishlist() in die Datenbank zurückgespeichert werden.
In keinem Fall darf also die UID von außen durch eine set-Methode änderbar 
sein!

Dabei fällt mir gerade noch was auf: Wenn die Klasse quasi eine 
Datenbanktabelle abbildet, dann mußt Du auch die Variablentypen zur Datenbank 
konform halten. $S_wishlistUID müßte also $I_wishlistUID sein (ich bemerke 
übrigens gerade, daß beides in der Klasse vorkommt, was sicher nur ein 
Flüchtigkeitsfehler ist). Außerdem mußt Du z.B. in 
setName($S_wishlistNewName) eine Prüfung durchführen, ob die übergebene 
Zeichenkette auch nicht die maximale Länge des Datenbankfelds von 255 Zeichen 
überschreitet. Dieselbe Prüfung mußt Du natürlich auch durchführen, wenn die 
Daten über den Konstruktor übergeben werden. Daher denke ich, daß - entgegen 
meinem Vorschlag - hier in diesem Fall Name und Passwort nicht über den 
Konstruktor übergeben werden sollten, sondern eben dann doch über die 
set-Methoden, weil diese ja noch zusätzliche Datenprüfungen enthalten und Du 
diese Prüfungen sinnvollerweise nicht im Konstruktor doppeln wirst. Der 
Konstruktor würde dann also optional nur eine UID übergeben bekommen.


> Meine Lösung für die saveWishlist()-Methode ist oben im code, gibt es
> dazu weitere Verbesserungsvorschläge?

In der Zeile 

	".mysql_real_escape_string($this->I_wishlistState).", 

kannst Du das mysql_real_escape_string weglassen. Das Feld ist ja vom Typ 
Integer. :-)

Bei der Funktion saveWishlist($I_wishlistUID, $DBlink) kann Du den Parameter 
$I_wishlistUID weglassen. Hier schlägt das prozeduralen Denken durch, daß 
einen einfach nicht loslassen will, wenn man auf OOP umsteigt. ;-) Du 
brauchst den Wert nämlich gar nicht zu übergeben, weil Du ihn doch schon im 
Objekt hast bzw. vor dem INSERT ermittelst: $this->I_wishlistUID ... :-)

Und die Zeile

	$I_saveWishlistResult = mysql_insert_id($DBlink);

muß wie folgt aussehen, weil ja die UID auch im Objekt, d.h. in der 
entsprechenden Objekteigenschaft, abgespeichert werden muß:

	$this->I_wishlistUID = mysql_insert_id($DBlink);


> Schwierigkeiten hatte ich mit
> dem DB link: im Namensraum der Klasse ist er ja anscheinend nicht
> bekannt, ich habe ihn daher mit übergeben. Gibt's da eine Alternative? [1]

[...]

> [1]: meine nette kleine $debug-Variable zum ein-/ausschalten der
> debugging-Ausgaben funktioniert ja auch nicht mehr, wäre in diesem Fall
> eine (super)Globale angebracht?

Eigentlich sehe ich bei Deiner Klasse nur diese zwei Möglichkeiten für $DBlink 
und $debug: Übergabe als Funktionsparameter oder Verwendung einer globalen 
Variablen. Oder Du müßtest das Ganze eben etwas anders ansetzen.


Viele Grüße
Lutz