Nimmt man bereits diese Vorauswahl, bleiben von den 5 M\u00f6glichkeiten noch 3 mit einem dicken ABER \u00fcbrig. Schauen wir also einmal genauer und stelen fest:<\/p>\n
- \n
- MySQLi Extension –> Bescheidenes Interface (gelinde gesagt)<\/li>\n
- MySQL Native Driver –> Overkill f\u00fcr meine Anwendung<\/li>\n
- PDO (PHP Data Objects) –> Wir wrappen einen Wrapper mit einem mWrapper, damit das Interface trotzdem Schei\u00dfe aussieht<\/li>\n<\/ol>\n
Nehmen wir also den Native Driver einmal raus, verbleiben noch genau zwei M\u00f6glichkeiten, einen Datenbank-Layer zu implementieren, die sicherlich auch von den meisten verwendet werden: MySQLi oder PDO.<\/p>\n
Wenn man sich nun anschaut, ob man mit einem bescheidenen Interface arbeiten muss oder gegen ein anderes, was genauso bescheiden ist, ist es einem im Endeffekt eigentlich egal, welches man davon nimmt. Vorteilhaft w\u00e4re f\u00fcr meinen Zweck zwar theoretisch PDO gewesen, da ich es gerne Datenbank-unabh\u00e4ngig gehabt h\u00e4tte, aber das habe ich recht schnell sein gelassen. Der Grund daf\u00fcr liegt in der Syntax der eingangs erw\u00e4hnten Prepared Statements, die ich als Voraussetzung hatte.<\/p>\n
Womit wir wieder bei dem Punkt bescheidene Interfaces w\u00e4ren: Ein Wunschkriterium war u.a. auch, dass der Datenbank-Layer Support f\u00fcr Named Parameters in Prepared Statements implementiert. Dies ist f\u00fcr PDO nicht der Fall. Vielmehr muss man durch massenhafte Rudelvorkommen von Fragezeichen die entsprechenden Stellen markieren, an denen man seine Parameter eingef\u00fcgt haben m\u00f6chte. Aus Perspektive der Lesbarkeit also das, was man zu allerletzt haben m\u00f6chte. Aber auch MySQLi bestach in seinem Interface: So wurden zwar benannte Parameter unterst\u00fctzt, „aus Kompatibilit\u00e4t“ wurde aber bei Mehrfach-Vorkommen eines Parameters immer nur das erste Vorkommen initialisiert – auch bei Mehrfach-Aufrufen. Stattdessen l\u00e4uft man in Fehlermeldungen, man h\u00e4tte zu wenige Parameter \u00fcbergeben. Eindeutig ein FAIL! WER bittesch\u00f6n denkt sich, dass man beim Bau einer Schnittstelle kompatibel zu den Fehlern anderer sein MUSS?!?!?!<\/p>\n
Also gut. In meiner Bibliothek hab ich das jetzt insofern behoben, dass meine Bibliothek einen Workaround um diese Sinnlosigkeit macht: Wenn ich mehrfach den gleichen Namen vergebe, m\u00f6chte ich auch, dass dort mehrfach der gleiche Wert ankommt. Und wie macht man das, wenn der zugrundeliegende Layer das nicht kann? Richtig, man emuliert es, durch Ersetzen von Variablen innerhalb der Query:<\/p>\n
\r\n \/**\r\n * DBStatement::_prepareHelper()\r\n *\r\n * @param mixed $m\r\n * @return\r\n *\/\r\n private function _prepareHelper($m)\r\n {\r\n $paramname = $m[1];\r\n\r\n if (!isset($this->params[$paramname])) {\r\n $this->params[$paramname] = array();\r\n }\r\n\r\n $dbmsparam = $this->paramCount++;\r\n\r\n $this->params[$paramname][] = $dbmsparam;\r\n\r\n return \"?\";\r\n }\r\n\r\n \/**\r\n * DBStatement::reprepare()\r\n *\r\n * @return\r\n *\/\r\n public function reprepare()\r\n {\r\n $this->params = array();\r\n $this->paramCount = 0;\r\n\r\n $_query = preg_replace_callback(\"\/:(\\w+)\\b\/\", array($this, '_prepareHelper'), $this->query);\r\n\r\n if (!$this->connection->ensureConnected()) {\r\n return false;\r\n }\r\n\r\n $this->query_res = $this->connection->getHandle()->prepare($_query);\r\n\r\n \/\/ ...\r\n }\r\n<\/pre>\nDieser Source ist im Grund nix weiter, als ein stark vereinfachter SQL-Parser, der lediglich Parameter in einer SQL-Query findet. Es sind noch eine Reihe von Vereinfachungen enthalten (? wird nicht als Parameter erkannt), aber das l\u00e4sst sich recht einfach nachr\u00fcsten. Auch das Ignorieren von Parametern innerhalb von Strings kann mit etwas Arbeit noch erg\u00e4nzt werden. Wenn man aber bedenkt, dass man schon zu solchen W\u00fcrgarounds greifen muss, um eine Abfrage vern\u00fcnftig an MySQLi abzusetzen, ist man \u00fcber solche Dinge wie „Wir binden das Ergebnis NUR an Variablen und verzichten auf die R\u00fcckgabe als Array“ schon fast eine Formalit\u00e4t. Also: Here we go (THX an Neo f\u00fcr das Finden dieses Tipps in den Kommentaren zur Dokumentation<\/a>):<\/p>\n
\r\n \/**\r\n * Bind the query to a variable for reading the result data\r\n *\r\n * @param mysqli_stmt $stmt\r\n * @param mixed $out\r\n * @return bolean Result of call.\r\n *\/\r\n function stmt_bind_assoc(mysqli_stmt &$stmt, &$out) {\r\n $data = mysqli_stmt_result_metadata($stmt);\r\n $fields = array();\r\n $out = array();\r\n\r\n $fields[0] = $stmt;\r\n $count = 1;\r\n\r\n while ($field = mysqli_fetch_field($data)) {\r\n $fields[$count] =& $out[$field->name];\r\n $count++;\r\n }\r\n\r\n return call_user_func_array('mysqli_stmt_bind_result', $fields);\r\n }\r\n<\/pre>\nWobei das Lesen nun wie von MySQL gewohnt erfolgen kann:<\/p>\n
\r\n \/\/ Init the result buffer\r\n $Result = array();\r\n \/\/ Try to bind the result buffer to the query\r\n if (!$this->stmt_bind_assoc($this->Query, $Result)) {\r\n throw new Exception(\"Cannot bind the result buffer to the query object.\");\r\n return false;\r\n }\r\n \/\/ Fetch the result line by line\r\n while ($this->Query->fetch()) {\r\n \/\/ Fetch and store the data into the object's result buffer\r\n $this->ResultSet[] = $Result;\r\n }\r\n<\/pre>\nBaut man nun noch ein wenig Magik drumherum, kann man daraus ein wunderbares, logisch strukturiertes Interface machen, was sich wie die alte MySQL-Extension verh\u00e4lt, sowohl Zeilenweise als auch insgesamt abrufbar ist und mit gerade einmal 3 Klassen eigentlich alles abdeckt, was man braucht:<\/p>\n
- \n
- DBConnection: Das Herzst\u00fcck jeder Verbindung zur Datenbank.<\/li>\n
- DBStatement: Ein Prepared-Statement und Funktionen zu dessen Nutzung<\/li>\n
- DBResultset: Ein Objekt, was jegliche Informationen \u00fcber das Ergebnis einer Abfrage kapselt<\/li>\n<\/ol>\n
Zus\u00e4tzlich ben\u00f6tigt man zwar u.U. eine weitere Klasse, die die Login-Informationen beinhaltet, aber das l\u00e4sst sich recht einfach realisieren. Verlgeicht man nun diese einfache Struktur mit dem Original-Interface von MySQLi, l\u00e4uft es einem allein bei MySQLi kalt den R\u00fccken runter: Nicht nur kann das Interface nicht sinnvoll dynamisch eingesetzt werden, erschwert wesentliche Aufgaben unn\u00f6tig und liefert obendrein essentielle Informationen an v\u00f6llig unlogischen Orten. Oder wer vermutet die letzte durch eine Abfrage generierte Datensatz-ID in der Verbindung, statt im Resultset-Objekt, was diese erzeugt hat? Um mal das Wort Konsistenz gar nicht weiter anzusprechen: Wenn man ein Prepared Statement ausf\u00fchrt, so muss man einige Ergebniswerte aus dem Prepared Statement lesen, obwohl diese zum Ergebnis geh\u00f6ren. Eben dieses bekommt man aber erst \u00fcber zahlreiche Umwege und dann enth\u00e4lt es auch nur die H\u00e4lfte der Angaben. Also muss man in einem Wrapper sich Daten aus 4 Klassen (mysqli, mysqli_stmt, mysqli_result und stdclass-Objekten) zusammensuchen, statt als Ergebnis einer Abfrage ein Resultset zu bekommen, in dem alle n\u00f6tigen Angaben zentral enthalten sind.<\/p>\n
Sobald ich mit dem Aufr\u00e4umen meines Datenbank-Layers und dessen Implementationn fertig bin, gibt es dazu auch noch ein Release.<\/p>\n
Wer PHP als PHrickle-Programm bezeichnet, hat eindeutig Recht.<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"