nicht angemeldet
echo $begrüßung;
» Allerdings darf das Setzen der Zugangsdaten - so du es doch von außen tun willst - nicht als Methode der Instanz implementiert sein. Denn in dem Fall müsste der erste Verwender die Zugangsdaten setzen und die anderen brauchen und dürfen das nicht mehr. Woher weiß denn aber der erste, dass er der erste ist?
Was meinst Du, wofür es die Methode getInstance() gibt und wofür ein Konstruktor vorhanden ist?
Zweitere ist mMn der richtige Platz, um Anfangswerte zu setzen!
Das Szenario sieht vor, dass es eine einzige Datenbankverbindung im gesamten Script gibt. Deswegen werwenden wir ja hier auch das Singleton-Pattern.
getInstance() ist für die Herausgabe der Instanz zuständig. Die Konfigurationsdaten hat es nicht entgegenzunehmen. getInstance() soll nämlich mehrfach aufgerufen werden können, je nach Bedarf und es soll dabei immer die selbe Datenbankverbindung verwendet werden. Die Verwender haben nicht die Aufgabe, sich um die Konfigurationsdaten zu kümmern.
Der Konstruktor ist im Singleton-Pattern primär vorhanden, damit man ihn privatisieren kann. Initialisierungsaufgaben kann er auch übernehmen, wenn das notwendig ist. Hier könnte er sich beispielsweise um das Holen der Konfigurationsdaten kümmern. Das kann aber auch erst die Connect-Funktion machen, denn die benötigt die Daten nur ein einziges Mal. Wenn die Verbindung erst einmal steht sind sie nutzlos.
Die Werte sollten der Query typgerecht übergeben werden. Dazu muss man aber die Spaltentypen, ihre Ranges und Defaults vorher beschaffen. Alternativ sind wir dann bei prepared Statements, weil eine textuelle Schnittstelle (SQL) bei Verwendung einer komplexen API/Datenbankklasse kaum noch Existenzberechtigung hat.
Dass das automatisierte Bedienen von Prepared Statements unter mysqli mit einigem Aufwand verbunden ist, habe ich im ursprünglichen Faden schon dargelegt und Chris mittlerweile erfolgreich davon abgebracht. Der Aufwand des Quotierens und Maskierens ist dagegen ein Kinderspiel. P.S. unter mysqli lohnen sich effektiv nur, wenn man sie in der in den Handbuchbeispielen gezeigten Weise verwendet.
Unter MySQL benötigt man eigentlich nur zwei Parametertypen: String und Ausdruck. Datums-und Zeit-Werte werden als String übergeben, mit Zahlen geht das ebenso problemlos. - Wenn man will, kann man jedoch die Parameter auf ihren Typ testen. Ist es ein Zahlentyp (is_int() oder is_float(), nicht aber is_numeric()), kann man ihn ohne Behandlung in die Query einbauen. Arrays, Objekte und Ressourcen sind abzulehnen. Boolean erfordert einen Typecast zu Integer. Auch Null ist testbar. Übrig bleiben Strings, die können mit der üblichen Behandlung in die Query eingefügt werden. Ob letztlich der Feldtyp passt ist aus sicherheitstechnischer Sicht egal. Die fachliche Püfung sehe ich als Aufgabe der Datenklasse und nicht der Datenbankklasse an. Die Datenbankklasse muss sich nicht prinzipiell gegen sämtliche Unfähigkeiten des anwendenden Programmierers schützen. Das ist schließlich Aufwand der auch bei fehlerfreier Verwendung betrieben werden muss. Mir reicht es für die allgemeine Anwendungszwecke, wenn sie sicherheitstechnisch keine Lücke aufweist.
Ausdrücke erfordern ein anderes Herangehen. Wenn es möglich ist, sollten sie natürlich direkter Bestandteil des Querystrings werden und nur eventuelle Parameter dieser Ausdrücke noch eingefügt werden müssen. Lässt es sich nicht vermeiden und man will unbedingt übergeben können, hat man ein kleines Problem, denn sie sehen auch wie Strings aus, dürfen aber nicht als solche behandelt werden. Abhilfe kann man mit einer kleinen Wrapperklasse schaffen. Wenn Parameter instanceof Ausdrucksklasse ...
echo "$verabschiedung $name";