dreamcatcher

Es hätte wenig Sinn gemacht, mit meinem alten Wissensstand hier weiter herumzudümpeln.

Daher schreibe ich nun ~2 Wochen später,
nachdem ich dazu kam das Zend Quickstart Tutorial sowie das letztes Tutorial einer "Zend Tutorial Reihe" zu Mappern anzuschauen & durchzuarbeiten.
__________________________________

Simpel:
Mir war vorher bei Zend kein anderes Pattern bekannt.

Während der Lehrstunden sind mir jedoch Unterschiede zu den Tutorial aufgefallen bzw. z.T. Unstimmigkeiten.

__________________________________

Grundannahme:
Da es ein beliebtes Beispiel ist, nehmen wir das Beispiel "Gästebuch".
In diesem kleinen Beispiel geht es nur darum alles auf einer Seite anzeigen zu lassen.
Als Pattern nehmen wir aus unserem Werkzeugkasten das DataMapper Pattern.

Version 1.)
Zend Framework Quickstart

Als allererstes macht das Quickstart die Aussage, dass "save", "find" und "fetchAll" quasi Default Methoden in einem Mapper sind.

Quelle:http://framework.zend.com/manual/en/...ate-model.html

Ist das richtig und wenn nein/ja, trifft es für alle Fälle zu ?

Vereinfachter Aufbau der Applikation:
/models/DbTable/Guestbook.php
/models/Guestbook.php
/models/GuestbookMapper.php
/controllers/GuestbookController.php

Wie fetchAll funktioniert:
Controller ruft neue Instanz des Mappers auf,
Controller übergibt an das View Objekt: Mapper->fetchAll
Mapper ruft interne getDbTable() Methode auf und greift somit durch eine Instanz von Zend_DbTable_Abstract (/DbTable/Guestbook.php) per fetchAll auf die DB zu.
Mapper erstellt per foreach() für jede Row ein eigenes Guestbook Obj. (/models/Guestbook.php), sammelt diese in einem Array und gibt dies letzendlich zurück.

Version 2.)
Video Tutorial (Siehe oben)

Vereinfachter Aufbau der Applikation:
/models/DomainAbstract.php
/models/DataMapperAbstract.php

/models/Guestbook.php
/models/GuestbookMapper.php
/models/GuestbookController.php

Wie fetchAll() funktioniert:
Controller ruft per getInstance() Methode eine Instanz von GuestbookMapper auf.
[Unterschied, bei Zend war es lediglich durch "new", hier wird es durch ein Singleton Pattern aufgerufen]
Controller übergibt an das View Objekt: Mapper->fetchAll
Mapper ruft $this->getDb Methode auf, welche zur Parentclass DataMapperAbstract führt und dort durch Zend_Db_Table::getDefaultAdapter() die derzeitige Verbindung holt.
Mapper baut die Query zusammen (->select()->from(tablename)) und führt danach auch die query durch ->fetchAll aus
[Unterschied, bei Zend wird nicht from() verwendet sondern durch die Instanz von Zend_DbTable_Abstract weiß die Applikation bereits die Tabelle]
Mapper erstellt per foreach() für jede Row ein eigenes Guestbook Obj. (/models/Guestbook.php), sammelt diese in einem Array und gibt sie letzendlich aus.

Weiterer Unterschied zum Zend Beispiel:
Das Model Guestbook.php ist ein Kind von DomainAbstract.php.
DomainAbstract hat als Property die $_id und die Methoden setId und getId.
Dies ist dafür gedacht nochmals ein wenig Tipparbeit zu sparen da man viele Klassen um diese erweitern kann
(So gut wie alles hat eine eindeutige Id um festzustellen ob ein update oder insert erfolgt)

Bei Zend gab es keine solche Abstract Class sondern die Property "Id" wurde direkt in das Objekt geschrieben.

Version 3.)
Google

Google sagt man sollte auf nicht benutzte Getter und Setter verzichten, der Performance wegen.
Meine Interpretation nach sollten somit auch "naive" (default) getter/setter vermieden werden.
[Siehe Zend]

Quelle:
http://code.google.com/intl/de-DE/sp...izing-php.html
__________________________________

Es ist schwer alles einigermaßen sauben zusammen zu bekommen, damit man es zumindest auf dem zweiten Blick erkennt.

Meine persönliche Einschätzung ist, dass beide Wege Vorteile haben die am besten sind.

Bei Zend Quickstart scheint es sauberer gelöst zu sein mit dem Zend_DbTable_Abstract, so dass der Mapper nicht von DataMapperAbstract per getDb den DefaultAdapter holen muss und dann extra eine "from()" Query erzeugt.
Allerdings wurde im VideoTutorial auch etwas gesagt dass DataMapperAbstract die interne Property $_db als static deklariert ist, so dass es wohl Performance gewinnen soll da diese nicht immer wieder neu erstellt werden muss.
Andererseits frage ich mich, was mir eine statische Variable bei PHP bringt, wenn nach der Scriptausführung sowieso der Speicher wieder leer ist.
Somit würde mir der Performancegewinn nur zur Seite stehen, sofern die Variable im selben Scriptaufruf nochmals abgefragt wird, was im Gästebuch nicht der Fall ist.

Bei der zweiten Variante kommt es mir hingegen sauberer vor mit der Abtrennung der AbstracClasses.
Dies bedeutet jedoch auch gleichzeitig erhöhten Schreibaufwand (und vllt. Performanceverlust, so dass es sinniger ist die Propertys alle in einem Model Objekt unterzubringen ?)

Es sind einfach einige unterschiedliche Ansätze, so dass ich mich riesig freuen würde wenn jemand jemand die Antwort darauf hat was nun besser ist:

Mit oder ohne solchen Abstract Classes
Mit oder ohne extra DbTable_Abstract Datei [Und dafür ggf. Queryzusammenbau mit "from(Tablename)" im Mapper]
Etc. pp..

Mister Ad

lcrash

Sehr ausführlich. Ich bevorzuge die im Quickstart beschriebene Struktur und habe dazu abstrakte Klassen entwickelt die Schreibarbeit abnehmen. Außerdem habe ich einen Project-Provider der meine Models aus der Datenbanktabelle erzeugt. Das ist auch der Grund warum ich bisher nicht auf Doctrine umgesattelt bin (auch wegen der nicht so guten Integration).

Das mit dem statischen $_db ist mir ein Rätsel. Wo soll das ein Perfomence-Gewinn bringen, wenn es eh nur eine Zend_Db-Instanz gibt? Und der DataMapper ist ein Singleton? Kommt selten vor, aber manchmal möchte ich zwei Dinge in einer Action separat behandeln und meine DataMapper hält dabei zwei verschiedene Models.

Getter/Setter sind bei mir optional und existieren aus historischen Gründen (früher behandelte ich Zend_Db_Row direkt).