nicht angemeldet
Hallo.
Gut, ich werde auf dynamisch erzeugte Statements verzichten.
Die DB-Klasse wird Singleton.
Die Tools/Help/Utility Klasse wird statisch aufgebaut, also die Funktionen werden static.
So kann ich ohne Sie zu instanzieren per Klassenname::Funktionsname() auf sie zugreifen.
Desweiteren werde ich die Requests immer örtlich behandeln, bei MySQLi mit P.S. ist dies nicht nötig da MySQLi dies übernimmt. Sie bekommen die unbehandelen Rohdaten.
Ich überlege gerade folgendes. Da MySQLi ja eh komplett OOP ist, brauche ich ja rein theoretisch garkeine DB Klasse. Ich wil trotzdem eine machen um ggf. irgendwann falls nötig auf ein anderes DBMS umsteigen zu können, eine DBKlasse machen.
Aber wenn man das jetzt mal alles zusammenfasst, sollte diese nur die Methoden "db_connect" sowie "db_prepare", "db_bind"(für bind_param / bind_result), "db_execute" beinhalten, welche ja voneinander abhängig sind irgendwo. Also packe ich die letzten Methoden jetzt in eine extra Klasse und sie bekommen das benötigte MySQLi-Objekt als Singleton oder kommen sie auch in die DB_Klasse und immer wenn ein MySQLi-Objekt per getInstance() erzeugt wird, wird dieses Objekt einer Variable der DBKlasse übergeben auf das die anderen Methoden der Klasse dann immer zurückgreifen können?
Tut mir leid wenn ich dir gerade das Gefühl gebe gegen ne Wand zu labern.
Ich schrieb gestern, die Statementerzeugung solle in die Basisklasse. Oben schrieb ich, jeder instantiiere sie sich selbst. Es kommt darauf an, was du letztlich implementierst. Willst du ein Prepared Statement erstellen inklusive der Instanz eines mysqli_stmt-Objekts,
Das check ich nicht.
dann lass es dir mit einer Methode der DBKlasse erzeugen, denn um ein mysqli_stmt zu bekommen musst du die mysqli-Klasseninstanz bemühen. Willst du ein SQL-Statement unabhängig von mysqli_stmt erstellen, also nur den Statement-String zusammensetzen, dann sollte eine Instanz vor Ort erzeugt werden.
Wir haben also nun zwei mögliche Wege
a) mysqli_stmt
b) SQL-Statement-StringFür a) gibt es DBKlasse::getStatememt(), damit bekommst du eine mysqli_stmt-Instanz. Der übergibst du den SQL-String sowie die Parameter, lässt das Ganze exekutieren und hast ein Ergebnis
Für b) erstellst du mit der SQL-String-Klasse den SQL-String und rufst
$db = DBKlasse::getInstance()
$result = $db->führeAus($sql_instanz)
auf.
Das verwirrt mich gerade.
Ich will das performante&sichere.
Also ich ging jetzt irgendwie davon aus einfach nur MySQLi zu benutzen als Singeton Pattern und wenn ich nun ein MySQLi Objekt erzeuge dann kann ich damit die Methoden prepare(), execute(), bind_param(), bind_result() usw nutzen. Ich verstehe nicht den Unterschied zwischen MySQLi_stmt und normalem MySQli oder isses beide das gleiche? Kann es ja nicht wie man hier und hier sieht. Aber irgendwie können sie doch nur beides das gleiche oder? Wann verwende ich denn was davon?
Mein Ziel war es einfach die Möglichkeit von Multi-Querys zu nutzen und die Tatsache das dass benutzen von Prepared Statements schneller und sicher ist, sowie das ganze OOP ist.
»» » Hier fehlt die kontextgerechte Behandlung der Strings. Ein O'Brien macht dir nur einen Syntaxfehler. Ein gezieltes Ausnutzen dieser SQL-Injection-Lücke gefährdet deinen Datenbestand.
»» Nein da es eine Klasse geben wird bzw. eine Funktion die alle $_Requests behandelt nach Magic Quotes. Zumindestens habe ich das so vor. hm...
Das lasse ich dann wie oben schon erwähnt sein.
Na, der Tabellenname kommt doch wohl nicht aus einer Benutzereingabe oder programmierst du phpMyAdmin nach?
Nein aber es wird eine Settings.php geben und dort stehen MySQL Daten, Tabellennamen mit Kommentierung usw. drin. D.h. wenn ich später iwas ändern muss, dann tu ich das erstmal in der Settings PHP. Wenn das etwas anders behandelt werden soll, an den Klassen.
Wie gesagt und in meiner ersten Antwort verlinkt, ist das Verwenden von Prepared Statements unter mysqli mit einer variablen Anzahl an Parametern mit einem aufwendigeren Handling verbunden als der herkömmliche Weg. Du bist mit herkömmlichen Weg genauso sicher wie mit P.S., wenn du an die kontextgerechte Behandlung denkst. P.S. bringen dir hier nur dann einen Vorteil (im Verhältnis zum Aufwand gesehen), wenn du ein P.S. mehrfach hintereinander ausführen kannst (z.B. Massen-Insert).
Dann bleibe ich bei P.S. denn das ist das was ich von Anfang an wollte. Einfach um meinen Horizont zu erweitern und aus den Gründen der in meiner Ansicht Vereinfachung.
Sie sind damit wie eine normale Funktion global [2], nur dass sie eben den Klassennamen zum Aufruf braucht.
Wo liegt denn dann der Unterschied zwischen Singleton P. und eine public static Methode? Letzteres ist sicherer aufgrund des Public Sichtbarkeitsmodofizierer?
Liebe Grüße,
Chris