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