Warum Zend_DB nicht so toll sein soll - Fortsetzung

[frankx]

Hellihello,

in diesem  Beitrag von Sven bezog er sich auf einen vorhergehenden Beitrag zu Zend_DB.

Darin:

... was an Zend_Db nicht so toll sein soll. Sinngemäßes Zitat: "Es abstrahiert genau die falschen Sachen, aber nicht die richtigen, und am Ende schreibt man objektorientiert SQL, addiert den Bloat des zusätzlichen Layers, gewinnt aber nichts."

Bloat meint wohl aufgeblasen und übermäßig Ressourcen fressend oder eben unnötig kompliziert vermutlich.

Mein aktuelles Verständnis reicht soweit:

Über die statische Methode Zend_DB::factory()lässt sich eine lazy Datenbankverbindung vorbereiten.
Der factory-Methode kann ein config-Objekt übergeben werden, dass die Inhalte einer ini-Datei repräsentiert,
die wiederum die nötigen Logindaten enthalten kann. Zend_DB_Adapter_Abstract ist die Basisklasse für alle
spezifizierten Adapter, und stellt beispielsweise die Methode "insert" und "update" zur Verfügung.

Steht beispielsweise in der config.ini

database.adapter       = "PDO_SQLITE"
database.params.dbname = "/data/guestbook.db"

so führt

  
$dbAdapter = Zend_Db::factory($configuration->database);  

zur Vorbereitungen für eine Sqlite-Datenbankanbindung zu "/data/guestbook.db".
Es wird eine Instanz der spefizierten Klasse erstellt, in dem Fall Zend_DB_Adapter_Pdo_Sqlite.
Die wiederum erbt von der abstrakten Klasse Zend_DB_Adapter_Pdo_Abstract,
welche auf PHPs PDO-
Extension basiert.

Zend_DB_Adapter_Pdo_Abstract beerbt die o.g. "Mutter aller Klassen"  Zend_DB_Adapter_Abtstract.
Somit verfügen alle Adapter z.B. über Funktion "insert", die aus Tabellenname
und einem assoziativen Spalten/Werte-Array ein "INSERT INTO" sql-Statement zusammen bastelt und ausführt.

Mit

  
Zend_Db_Table_Abstract::setDefaultAdapter($dbAdapter);  

lässt sich nun eine Implementation von Fowlers
"Table-Data-Gateway-Pattern" nutzen,
die ihrerseits u.a. über die Methoden insert, update und delete verfügt.

(Fowler hierzu: "Mixing SQL in application logic can cause several problems.
Many developers aren't comfortable with SQL, and many who are comfortable may not write it well.
Database administrators need to be able to find SQL easily so they can figure out how to tune and evolve the database. A Table Data Gateway holds all the SQL for accessing a single table or view:
selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database.")

Für o.g. Beispiel sähe dann die erbende Klasse so aus:

  
class Model_DbTable_GuestBook extends Zend_Db_Table_Abstract  
{  
    /** Table name */  
    protected $_name    = 'guestbook';  
  
    /**  
     * Insert new row  
     *  
     * Ensure that a timestamp is set for the created field.  
     *  
     * @param  array $data  
     * @return int  
     */  
    public function insert(array $data)  
    {  
        $data['created'] = date('Y-m-d H:i:s');  
        return parent::insert($data);  
    }  
  
    /**  
     * Override updating  
     *  
     * Do not allow updating of entries  
     *  
     * @param  array $data  
     * @param  mixed $where  
     * @return void  
     * @throws Exception  
     */  
    public function update(array $data, $where)  
    {  
        throw new Exception('Cannot update guestbook entries');  
    }  
}  

(s.a. ZF-Quickstart)

Im Quickstartbeispiel wird noch eine Model-Klasse erstellt, die Fowlers
http://martinfowler.com/eaaCatalog/tableModule.html Table-Module-Pattern folgt. Deren Methode "save"
filtert zu speichernde Daten anhand der verfügbaren Tabellenspalten, bevor es sie an eine Instanz der
Zend_DB_Table_Abstract-Klasse zum Speichern übergibt.

Im Controller wird vorher übrigens via Zend_Form die Validität der Daten geprüft.

Für mich scheint das alles sinnig und logisch. Wo steckt den hier der "Bloat", oder ist das auch "Ansichtssache"?

Dank und Gruß,

frankx

[Sven Rautenberg]

Moin!

»» ... was an Zend_Db nicht so toll sein soll. Sinngemäßes Zitat: "Es abstrahiert genau die falschen Sachen, aber nicht die richtigen, und am Ende schreibt man objektorientiert SQL, addiert den Bloat des zusätzlichen Layers, gewinnt aber nichts."

Bloat meint wohl aufgeblasen und übermäßig Ressourcen fressend oder eben unnötig kompliziert vermutlich.

Der Kritikpunkt ist (aber ich betone, dass ich da nur Ansichten ungefiltert weitergegeben habe), dass die falschen Sachen abstrahiert werden, nicht der Bloat.

Für mich scheint das alles sinnig und logisch. Wo steckt den hier der "Bloat", oder ist das auch "Ansichtssache"?

- Sven Rautenberg

[frankx]

Hellihello Sven,

»» »» ... was an Zend_Db nicht so toll sein soll. Sinngemäßes Zitat: "Es abstrahiert genau die falschen Sachen, aber nicht die richtigen, und am Ende schreibt man objektorientiert SQL, addiert den Bloat des zusätzlichen Layers, gewinnt aber nichts."
»»
»» Bloat meint wohl aufgeblasen und übermäßig Ressourcen fressend oder eben unnötig kompliziert vermutlich.

Der Kritikpunkt ist (aber ich betone, dass ich da nur Ansichten ungefiltert weitergegeben habe), dass die falschen Sachen abstrahiert werden, nicht der Bloat.

Das wäre die Implentation des Table-Data-Gateway-Patterns bzw. des Table-Module-Patterns? Oder die Nutzung der PDO-Extension?

Mir ist schon klar, dass Du da nur weitergibst, so hoffte ich, dass meine Zusammenfassung zumindest insoweit dem kundigen Lese einen Überblick geben würde, als dass man die Stelle, an der die Kritik greift, lokalisieren könnte.

Außer Dir und dedlfix schaut hier vermutlich ja eh keiner Vorbei, bzw. fehlt dann auch die Kenntnis und/oder das Interesse.

Dank und Gruß,

Robert aka

frankx