PDO: Dynamische Read- und Write-Funktion schreiben

[borisbaer]

Hallo T-Rex,

ich lese da ein "self::prepare".

Das heißt für mich, dass du in einer Klasse, in der das PDO Objekt steckt, die SQL Statements zusammenbauen willst. Ich hab ein paar Regeln beim Programmieren. Eine Davon ist "Trennung der Anliegen".

Separation of Concerns. Ja, das kenne ich. Ich habe in meiner App-Klasse im Constructor folgende statische Instanziierung (sagt man das so?) der Database-Klasse: static::$db = new Database( $config -> db ?? [] ); In derselben App-Klasse habe ich dann noch eine statische Methode, mit der andere Klassen die Database-Klasse leicht instanziieren können:

public static function db(): Database

{ return static::$db; }

In der Database-Klasse steckt dann sowohl die Konfiguration für die Datenbank-Verbindung als auch die prepare-Methode für SQL-Anfragen (müsste wohl eher getPreparedStmt heißen):

public function prepare( $sql ): PDOStatement

{ return $this -> pdo -> prepare( $sql ); }

Diese Lösung habe ich mir nicht selbst ausgedacht, sondern sie von einem anderen MVC-Framework abgeschaut. Ich fand sie elegant und zielführend. Mit dem PDO-Modul bin ich leider kaum vertraut. Kenne nur ein paar grundlegende Befehle.

Ich habe selbst eine PDO Klasse, die ein paar mehr Funktionen bereit hält als das php übliche PDO selbst. So z.B. query( $query, $data ). Das ist die Schnittstelle an der das prepare und execute passiert + Fehlerbehandlung.

Der $query kann entweder ein String sein oder es wird ein Objekt "Query_Builder" übergeben. Dieser hilft mir beim bilden eines Querys. Da kann man z.b. einen Select hinzufügen select( $select, $alias) oder man fügt ein where() hinzu. Diese Dinge Select, Where oder was auch immer können wiederum Objekte sein. Am Ende bekomme ich vom Query_Builder ein fertiges Query getQuery().

Ja, das ist durchaus sinnvoll. Wenn ich bei GitHub schaue, dann fällt mir natürlich auch auf, dass jede Methode in der Regel möglichst nur eine Sache macht. Das Ergebnis sind dann manchmal Klassen mit zig Methoden. Wahrscheinlich liegt das an meinem Skill-Level, aber ich persönlich finde tatsächlich zu kleingliedrigen „Methoden-Bau“ nicht wirklich übersichtlich. Ist wohl auch immer an das gebunden, was man letztlich mit dem Framework bzw. der Library machen möchte und für wen sie geschrieben wird. In der Regel sollen sie ja General-Purpose-Lösungen sein. Das Framework, an dem ich arbeite, ist jedoch nur an die Anliegen meiner Website angepasst.

Was ich dir damit zeigen möchte ist, dass ich ein großes Thema in viele kleine Bausteine zerlegt habe. Die sind leichter zu verstehen und zu testen. Vor allem kann man diese sehr leicht in UnitTests packen.

Das Thema UnitTesting habe ich mir noch gar nicht angeschaut. Das steht momentan ziemlich weit hinten auf der Agenda.

Datenbankfelder kannst du dann über "echte" Models definieren ... aber da wurde dir ja schon geholfen.

Was meinst du mit „echten“ Models? Was wären denn „unechte“?

Deswegen, hab keine Angst neue und vor allem kleine Klassen an zu legen. Teile und Herrsche !

Danke für die Tipps!

Grüße
Boris