nicht angemeldet
Hi!
ist nicht bereits die MySQLi-Klasse im Stande selbstständig die Verbindungen zu verwalten.
Nein, nicht Verbindung_en_, nur eine.
So habe ich wirklich nur das Gefühl, als würde ich einen Wrapper schreiben.
Jein. Sieh die Einfachheit meiner Klasse. Der Mehrwert liegt darin, dass kein Connect mit Test, kein Kodierungsaushandeln, nicht zwangsläufig ein Quoten und Zusammenbauen eines Statements stattfinden muss. Einfach nur (ein einmaliges Initialisieren am Scriptanfang und) ein query()-Aufruf in einem try-catch-Block. Der Verwender kann sich ganz auf seine Geschäftslogik konzentrieren.
Auch ist mir unklar, warum es in diesem Fall statisch sein sollte, da es hier für mich durchaus Sinn machen würde, mehrere Objekte (mit unterschiedlichen Datenbankverbindungen) zu erzeugen.
Ja, es ist sinnvoll, mehrere Verbindungen haben zu können, aber wann braucht man das schon? Selten. Deswegen kann ich hier auch den Aufwand aus Verwendersicht so gering wie möglich halten. Selbst das Instantiieren und Rumschleppen eines DB-Objekts spar ich mir durch den statischen Aufruf.
Die Quote()-Methode braucht es auch nur selten, denn, erwähnt hatte ich es noch nicht, aber die Query()-Methode nimmt das Statement mit Platzhaltern entgegen sowie ein Array mit den Werten und baut sich selbst ein ordentliches, sicheres Statement selbst zurecht. Ob es dazu Prepared Statements oder sprintf() nimmt, steht auf einem anderen Blatt.
Hier einfach mal die Klasse, die ich anhand deines Schemas geschrieben habe:
Das ist dann wirklich nur mehr oder weniger ein Wrapper. Wenn du das so machst, musst du immer ein DB-Objekt herumtragen. Oder du nimmst das Factory-Pattern, um dir bei tatsächlichem Bedarf eine Instanz zu holen. Die kannst du nach getaner Arbeit fallen lassen, weil sie sich der Nächste auch wieder über die Factory holt.
$db = DB::GetConnection('foo');
$db->...
Vorbereitend muss der DB-Klasse noch mitgeteilt werden, was die Verbindung foo ist.
DB::InitConnection('foo', Parameter_der_ersten_Verbindung);
DB::InitConnection('bar', Parameter_der_zweiten_Verbindung);
Der erste Parameter ist ein eindeutiger Name, der Rest - in welcher Form auch immer - die Parameter der Verbindung. DB merkt sich die Daten intern. Die Factory-Methode gibt die Verbindung mit passendem Namen heraus und erstellt sie vorher aus den Konfigurationsdaten, wenn das noch nicht geschehen ist.
In meinen Augen bietet diese Klasse die gleichen Möglichkeiten wie die MySQLi-Klasse (nur dass ich noch die quote_identifier-Methode hinzugefügt habe).
Der Mehrwert für den Verwender muss mindestens den Aufwand der Erstellung übersteigen, sonst wird das Ganze ineffizient.
Mir war nicht bewusst, dass ich auch in Funktionen statische Variablen anlegen kann. Daher hat dein Text für mich keinen Sinn ergeben. Ist das eigentlich in anderen Programmiersprachen (Java, C++) auch möglich?
In Java kann man, wenn ich mich recht erinnere, keine klassenlosen Funktionen erstellen. Also hast du mindestens eine Klasse, der du eine (private) statische Eigenschaft als Ablage verpassen kannst. Das selbe bei C#. C++ entzieht sich meiner Kenntnis.
Lo!