nicht angemeldet
Datenbankverbindung als Objektvariable?
Hallo,
Ich habe eine Klasse, die als PHP-Gegenstück eine MySQL-Tabelle dienen soll. Soll bedeuten, dass diese Klasse Informationen über die Felder der Tabellen in diversen Arrays hält. Es gibt also ein Array für die Schlüsselfelder, eines für Pflichtfelder (solche, die ein Benutzer in einem Formular auf jeden Fall ausfüllen muss) und eines für alle anderen Felder. Diese Klasse hat u.a. Funktionen für Einfüge-, Änder-, Abfrage- und Löschoperationen auf der Datenbank.
Sinn soll sein, dass bei einer Änderung der Datenbank nicht allzuviel am Quellcode an den SQL-Anweisungen geändert werden muss. Außerdem kann von dieser Klasse geerbt werden, so dass sie relativ schnell an andere Tabellen angepasst werden. (Quelle: "Methode des aktiven Datensatzes" aus PHPsolutions 5/2006)
Soviel zur Vorabinformation. Meine Frage ist nun, ob die Datenbankverbindung als Variable bei dem Objekt gespeichert werden soll/kann/darf/muss oder nicht. Der Vorteil wäre, dass ich Quellcode spare, da ich nur den Konstruktor entsprechend ändern muss. Die Alternative wäre, die Datenbankverbindung in den oben angesprochenen Funktionen aufzubauen.
Was ist eure Meinung dazu?
Viele Grüße und schöne Feiertage,
Stefan
-
Ich habe eine Klasse, die als PHP-Gegenstück eine MySQL-Tabelle dienen soll.
Vorsicht, sowas bringt normalerweise Pech.
Sinn soll sein, dass bei einer Änderung der Datenbank nicht allzuviel am Quellcode an den SQL-Anweisungen geändert werden muss.
Genau das geht eigentlich nicht, wenn Du alles doppelt moppelst, d.h. Du erzeugst Abhaengigkeiten.
Soviel zur Vorabinformation. Meine Frage ist nun, ob die Datenbankverbindung als Variable bei dem Objekt gespeichert werden soll/kann/darf/muss oder nicht.
Brrr. Mach das bitte nicht. Stell Dir einfach mal vor, dass Du das konsequent durchziehst und es werden zig Verbindungen zum DBServer aufgebaut. Oder nicht abgebaut.
-
Ich habe eine Klasse, die als PHP-Gegenstück eine MySQL-Tabelle dienen soll.
Vorsicht, sowas bringt normalerweise Pech.
Du scheinst aus Erfahrung zu sprechen. Was für Pech denn?
Sinn soll sein, dass bei einer Änderung der Datenbank nicht allzuviel am Quellcode an den SQL-Anweisungen geändert werden muss.
Genau das geht eigentlich nicht, wenn Du alles doppelt moppelst, d.h. Du erzeugst Abhaengigkeiten.
Meinst Du mit Abhängigkeiten, dass ich, wenn ich der Tabelle ein Feld hinzufüge, auch meine Klasse entsprechend ergänzen muss? Aber in diesem Fall muss ich doch sowieso Änderungen im Code vornehmen.
Brrr. Mach das bitte nicht. Stell Dir einfach mal vor, dass Du das konsequent durchziehst und es werden zig Verbindungen zum DBServer aufgebaut. Oder nicht abgebaut.
Wie lange bleibt denn ein Objekt erhalten und damit dessen Datenbankverbindung? Wenn ich die Variable mit unset() zerstöre, dann ist doch auch das Objekt weg, oder?
-
Ich habe eine Klasse, die als PHP-Gegenstück eine MySQL-Tabelle dienen soll.
Vorsicht, sowas bringt normalerweise Pech.
Du scheinst aus Erfahrung zu sprechen. Was für Pech denn?
Ja, ich muss das ein wenig relativieren. Was Du machen kannst ist selbstverstaendlich den ¨"kruden" Datenzugriff CRUDL in geeignete Module bzw. Klassen packen, also erst einmal abstrakt ein Objekt hochkommen lassen und erst dann mit einem Create bzw. INSERT oder einem Read bzw. SELECT oder einem Update bzw. einem UPDATE oder einem Delete bzw. DELETE kommen. Dann haettest Du "das SQL" im Klassenmodul, das waere OK. Allerdings Vorsicht mit unnoetigem Datenzugriff per SQL!
Wenn Du aber mit Stored Procedures arbeitest, die bereits den CRUD-Datenzugriff bereitstellen, dann empfehle ich den Verzicht auf den Datenzugriff irgendwie nachbauende Objekte.
Wovon ich auch abrate ist ein sich Aufbauen der Datenzugriffsobjekte zur Laufzeit, bspw. mithilfe von Schemaabfragen und anschliessender automatisierter Erstellung des CRUD-Datenzugriffs.
Anmerkung: CRUD ist heutzutage natuerlich eher CRUDL + Analyseabfragen.Sinn soll sein, dass bei einer Änderung der Datenbank nicht allzuviel am Quellcode an den SQL-Anweisungen geändert werden muss.
Genau das geht eigentlich nicht, wenn Du alles doppelt moppelst, d.h. Du erzeugst Abhaengigkeiten.
Meinst Du mit Abhängigkeiten, dass ich, wenn ich der Tabelle ein Feld hinzufüge, auch meine Klasse entsprechend ergänzen muss? Aber in diesem Fall muss ich doch sowieso Änderungen im Code vornehmen.
Wenn Du - wie zuerst beschrieben - vorgehst, dann muesste das OK sein.
Wie lange bleibt denn ein Objekt erhalten und damit dessen Datenbankverbindung? Wenn ich die Variable mit unset() zerstöre, dann ist doch auch das Objekt weg, oder?
Warum laesst Du nicht anfaenglich ein selbstgebautes Verbindungsobjekt hochkommen oder nimmst das Angebotene?
Ich habe schon genug Anwendungen gesehen, die zuviele Verbindungen aufbauen. Ich sehe auch keinen Grund jerweils eine Datenverbindung in einem der den Tabellen nachgebildetetn Klassen auf- und ggf. abzubauen.
-
Hallo Henrico,
[...] Anmerkung: CRUD ist heutzutage natuerlich eher CRUDL + Analyseabfragen.
Hmmmhmm... soso... CRUDL... ach ja, dass... ja ne, ist klar...
Da hast Du mir aber ordentlich einen vor den Latz geknallt. Nur gut, dass ich jetzt Urlaub habe und mich damit in Ruhe beschäftigen kann.Warum laesst Du nicht anfaenglich ein selbstgebautes Verbindungsobjekt hochkommen oder nimmst das Angebotene?
Wenn das die eleganteste Lösung ist, dann werde ich es so machen. Wahrscheinlich denke ich manchmal zu kompliziert.
Viele Grüße,
Stefan
-
[...] Anmerkung: CRUD ist heutzutage natuerlich eher CRUDL + Analyseabfragen.
Hmmmhmm... soso... CRUDL... ach ja, dass... ja ne, ist klar...
LOL - http://de.wikipedia.org/wiki/CRUD
Da hast Du mir aber ordentlich einen vor den Latz geknallt. Nur gut, dass ich jetzt Urlaub habe und mich damit in Ruhe beschäftigen kann.
Ach, das ist doch ganz elementar, das ist das INSERT, UPDATE, SELECT und DELETE.
(C)reate - INSERT
(R)ead - SELECT
(U)pdate - UPDATE
(D)elete - DELETE
(L)ist - SELECT
-
-
-
-
-
Hallo !
Soviel zur Vorabinformation. Meine Frage ist nun, ob die Datenbankverbindung als Variable bei dem Objekt gespeichert werden soll/kann/darf/muss oder nicht. Der Vorteil wäre, dass ich Quellcode spare, da ich nur den Konstruktor entsprechend ändern muss. Die Alternative wäre, die Datenbankverbindung in den oben angesprochenen Funktionen aufzubauen.
Auf- und abbbauen pro Funktion halte ich fuer unguenstig; die Verbindung wuerde ich zumindest waehrend einer Sitzung halten wollen.
"zumindest" da ich nicht weiss ob es bei Apache/"PHP 5" sowas wie ein Application-Objekt unter ASP gibt.Es gibt imho aber noch eine Design-Alternative:
Eine Klasse, am besten ein Singleton, die die Verbindung(en) kapselt und moderiert und die Deine Datenzugriffsokjekte-Objekte mit einem Verweis auf sich selbst oder eine Verbindungs_referenz_ ( _keine_ Kopie ! ) erzeugt, also eine Factory.
Wie waer das denn ?
Bin aber kein PHP 5 Experte.
Gruesse
Holger
Was ist eure Meinung dazu?
Viele Grüße und schöne Feiertage,
Stefan
-
Hallo Holger,
Eine Klasse, am besten ein Singleton, die die Verbindung(en) kapselt und moderiert und die Deine Datenzugriffsokjekte-Objekte mit einem Verweis auf sich selbst oder eine Verbindungs_referenz_ ( _keine_ Kopie ! ) erzeugt, also eine Factory.
Ich habe ein Klasse, die Datenbankverbindungen aufbauen, schließen und Abfragen ausführen kann. Mit meinen autodidaktischen Kenntnissen vermute ich, dass Du so etwas meinst?
-
Hallo Stefan !
Hallo Holger,
Eine Klasse, am besten ein Singleton, die die Verbindung(en) kapselt und moderiert und die Deine Datenzugriffsokjekte-Objekte mit einem Verweis auf sich selbst oder eine Verbindungs_referenz_ ( _keine_ Kopie ! ) erzeugt, also eine Factory.
Ich habe ein Klasse, die Datenbankverbindungen aufbauen, schließen und Abfragen ausführen kann. Mit meinen autodidaktischen Kenntnissen vermute ich, dass Du so etwas meinst?
Ja, aber ich will daruas nich nur eine beliebige Klasse sondern eine Klasse mit nur einem Objekt ( Instanz, Exemplar ) machen - eben ein Singleton(*) und zudem Datenzugriffsobjekte erzeugt - eben eine Fabrik(*).
Gruesse
Holger
P.S.: (*) Beide sog. "Muster" sind hier erklaert. Sonst nach Google "GoF" "Pattern" "Muster" "Wikipedia" o.ae.
-
-