[Erledigt] PDO Wrapper?

[jspit]

Und welche Funktionalität willst du hinzufügen ?

Da tiefer einzusteigen ist etwas OT. quoteIdentifiers z.B. , ist ansatzweise hier schon diskutiert worden.

LG jspit

[Gast]

Ok, um beim Beispiel Gästebuch zu bleiben: Wenn ich z.B. zusätzlich $_POST['antwort'] übergeben möchte, wird somit der konstruktor ziemlich dick, weil ich die objekte, UND parameter übergebe. Hat sich da eine best practise eingebürgert, dass man parameter z.B. mittels setter injection übergibt, und Objekte und Paramteter schön getrennt übergibt, oder haut man einfach alles in den Konstruktor?

[tr0y]

$_POST['antwort'] übergibst du nicht dem Constructor. Guestbook ist ein Verwaltendes Objekt das als Repository fungiert und das bekommt eine query-Methode zum speichern eines Eintrags.

$guestbook = new GuestBook($pdo);
$guestbook->store($_POST['autor'], $_POST['antwort']); 

[Gast]

Verstehe verstehe. Das war Wissensgenerierung meinerseits von 0 auf 100
Ich denke nun habe ich alles verstanden.

[Tropi]

Zu $_POST['antwort'] siehe tr0y. Ansonsten stehen auf Wikipedia die 3 Möglichkeiten zur Dependency Injection zusammengefasst: http://en.wikipedia.org/wiki/Depende...ency_injection

ad "von 0 auf 100": Keine Sorge, du schlägst dich gut.

[tr0y]

Merke dir Folgendes: In den Constructor injiziert gehört was auf jeden Fall notwendig ist um ein Objekt zu instanziieren. Setter sollten zur verfügung stehen wenn etwas nach der Instanziierung ausgetauscht werden können soll ( sofern es denn auch per constructor gesetzt worden ist ) oder wenn etwas zusätzlich zu den abhängigkeiten im Constructor einem Objekt injiziert werden kann.

[Gast]

Nun stehe ich bei 102%

[tr0y]

Da tiefer einzusteigen ist etwas OT. quoteIdentifiers z.B. , ist ansatzweise hier schon diskutiert worden.

LG jspit

Jede Wette das so gut wie jede Methode die du implementieren willst ( inklusive der in dem verlinkten Thema ) nichts in einem Database Abstraction Layer zu suchen hat und eigentlich Teil eines Query-Builders sein sollte.

Erweiterte Funktionalität die direkt den DAL betrifft und die Zuständigkeit der Verbindungsinteraktion besitzt ist gerade bei PDO sehr rar, da PDO schon weitestgehend alles umgesetzt hat was man in einem DAL benötigt.

[lottikarotti]

Hallöchen,

Was spricht dagegen, PDO zu erweitern?

Generell spricht nichts dagegen, Klassen um die eigenen Bedürfnisse zu erweitern - das ist nunmal Teil von OOP. Ich persönlich halte allerdings nicht viel von Wrappern, welche, bis auf ein wenig mehr Overhead zu erzeugen, keinen konkreten Mehrwert bringen. PDO bietet schon ein recht simples Interface für die meisten Anwendungsfälle, weshalb man sich einen Wrapper, wie der TE ihn vorgeschlagen hat, sparen kann.

@Lotti: Herzlichen Dank für deine Mühe, genau das, was ich brauchte. Meinen höchsten Respekt vor dir.
Jetzt hab ich zwangsläufig noch eine Zusatzfrage: Sollte ich dann die Gästebuch Klasse auch so gestalten, dass zwangsläufig alle Objekte, die sie benötigt, über den Konstruktor "reinkommen" nach deinem genannten Prinzip, weil somit sind die Klassen ja noch mehr voneinander entkoppelt. Weitere Klasse wäre z.B. dass ein Gästebuch zusätzlich ein Captchaobjekt benötigt.

Du darfst nun natürlich nicht den Fehler machen und alles in den Konstruktor quetschen. Deinen Methoden ist es weiterhin gestattet, Parameter zu erwarten, welche für die jeweiligen Aufgaben notwendig sind (siehe tr0y's Beitrag). Bei Dependency Injection geht es in erster Linie darum, die Abhängigkeiten zwischen Objekten lose zu gestalten. Dies hat den Vorteil, dass die Implementierung einer Abhängigkeit jederzeit ausgetauscht werden kann, ohne den Code der abhängigen Klasse anfassen zu müssen (siehe Tropi's Beitrag).

Viele Grüße,
lotti

[rkr]

Es gibt schon noch eine Menge Gründe PDO zu wrappen*:

PDO::__construct()
* UTF-8 als Standard
* Exceptions als Standard
* URI statt "dsn/username/password/options" (mysql://user:pass@host:port/dbname?option1=&option2=&option3=)

PDO::exec() / PDO::query()
* Zweiter parameter = Parameterlist (wie http://www.php.net/manual/de/pdostatement.execute.php)
* Neue Methoden: queryAsObject(), queryAsObjects() etc

PDOStatement::fetch() / PDOStatement::fetch*()
* PDOStatement::execute() wird automatisch aufgerufen, wenn noch nicht geschehen

Ansonsten haengt es immer sehr von den Anforderungen der Domäne ab. PDO ist im Standard noch sehr geschwätzig. Heisst, man braucht häufig mehr Code als wirklich notwendig.

Wrappen heisst nicht notwendigerweise PDO zu erweitern. Man kann PDO auch als innere Instanz halten und so vor der Aussenwelt abschirmen (Delegation).

[ApoY2k]

Oder man nimmt einfach Doctrine DBAL. Da ist das alles schon drin

[lottikarotti]

Hallöchen,

Ansonsten haengt es immer sehr von den Anforderungen der Domäne ab. PDO ist im Standard noch sehr geschwätzig. Heisst, man braucht häufig mehr Code als wirklich notwendig.

"Geschwätzig" ist gut

In den meisten meiner Projekte mit kleinem bis mittlerem Umfang komme ich ganz gut mit der zentralen Instanziierung von PDO hin - wobei ich generell doch lieber auf Doctrine setze und diese Verantwortung abgebe (nur mal als persönlicher Einblick). Ich wollte aber auch nicht sagen, dass Wrapper generell verboten gehören. Das sind natürlich Design-Entscheidungen die der Entwickler, abhängig von den Gegebenheiten und den Anforderungen, selbst treffen muss. Wenn man PDO exzessiv verwendet, womöglich sogar mit unterschiedlichen Konfigurationen usw., bietet es sich sicherlich an, alles hinter kompakten Methoden zu kapseln, was sich ständig wiederholt oder konfiguriert werden muss.

Ich finde es aber sehr wichtig, Anfänger dafür zu sensibilisieren, wann solche Lösungen konkret notwendig sind und wie diese im Optimalfall aufgebaut sein sollten. Ich sehe es oft, dass krampfhaft alles erdenkliche hinter Klassen versteckt wird, nur des OOP-Zwecks wegen. Da liegt der Fehler meines Erachtens oft im Ansatz und in der Denkweise bzw. der Interpretation von OOD. Da schießt man, gerade als Anfänger, ganz schnell über das Ziel hinaus.

Viele Grüße,
lotti

[Gast]

Ein kleines Frägchen tut sich doch noch auf. Ich nutze für die Speicherung der Datenbankeinträge zusätzlich die von PHP bereitgestellte Klasse DateTime. Dort muss, um den genauen Zeitpunkt zu erhalten, eine Zeitzone gesetzt werden und dem ganzen ein Format mitgegeben werden. Und hier häng ich ein bisschen: DI würde ja bedeuten, dass ich dann jedes mal beim Erzeugen des Gästebuches die Art und Weise, wie ich die Zeit festhalten möchte, mitübergeben muss im Konstruktor. Ist es in diesen Fällen sinnvoll das Objekt "fest in die Klasse zu kodieren", da es nicht ausgetauscht wird. Zusätzlich: Soll ich eine Fassade für DateTime verwenden, das mir die Erzeugung abnimmt, da das Format (YYYY:MM) auch fest in der Datebank steht und nicht verändert werden soll? Hoffe habe mich klar ausgedrückt.

[lottikarotti]

Hallöchen,

Ein kleines Frägchen tut sich doch noch auf. Ich nutze für die Speicherung der Datenbankeinträge zusätzlich die von PHP bereitgestellte Klasse DateTime. Dort muss, um den genauen Zeitpunkt zu erhalten, eine Zeitzone gesetzt werden und dem ganzen ein Format mitgegeben werden. Und hier häng ich ein bisschen: DI würde ja bedeuten, dass ich dann jedes mal beim Erzeugen des Gästebuches die Art und Weise, wie ich die Zeit festhalten möchte, mitübergeben muss im Konstruktor. Ist es in diesen Fällen sinnvoll das Objekt "fest in die Klasse zu kodieren", da es nicht ausgetauscht wird. Zusätzlich: Soll ich eine Fassade für DateTime verwenden, das mir die Erzeugung abnimmt, da das Format (YYYY:MM) auch fest in der Datebank steht und nicht verändert werden soll? Hoffe habe mich klar ausgedrückt.

Muss das Gästebuch denn wirklich wissen *wie* das DateTime-Objekt erzeugt wird? Das Ausgabeformat wäre bspw. Teil deiner Anwendungskonfiguration. Die DateTime-Objekte werden vermutlich an einer anderen Stelle erzeugt (bspw. bei der Erzeugung eines Kommentars). An dieser Stelle müssen natürlich alle Informationen bekannt sein, welche deine Anwendung benötigt, um das entsprechende Objekt ordentlich erstellen zu können. Pauschal kann man das aber nicht beantworten.

Viele Grüße,
lotti

[Gast]

Muss das Gästebuch denn wirklich wissen *wie* das DateTime-Objekt erzeugt wird?

Nein, es muss nur eins haben. Deshalb dachte ich, ich schreibe eine Fassade, die mir alles nötige erzeugt für DateTime und übergebe ein Objekt dieser Fassade direkt ins Gästebuch, weil ich es für wenig sinnvoll halte, an dieser Stelle DI anzuwenden. Was meinst du?