Zend Framework Gateway dati tabella in stile ORM rispetto all'estensione Zend_Db_Table_Abstract

Question

Nel Zend Framework Quickstart, è stato modificato il modello che estende Zend_Db_Table_Abstract nel modello di Gateway dati tabella.

Personalmente, non ho avuto molta esperienza con questo modello e continuo a sentirlo che molto probabilmente dovrebbe essere usato al posto del vecchio modo.

Un breve esempio dal QuickStart:

Vecchio modo:

class Default_Model_Guestbook extends Zend_Db_Table_Abstract 
{ 
    protected $_name = 'tablename'; 

    // do stuff 
} 

Nuovo modo:

// The actual model 
class Default_Model_Guestbook 
{ 
    protected $_comment; 
    protected $_created; 
    protected $_poster; 
    // list continues with all columns 
} 

// Dbtable for this model 
class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract 
{ 
    /** Table name */ 
    protected $_name = 'guestbook'; 
} 

// Mapper 
class Default_Model_GuestbookMapper 
{ 
    public function save($model); 
    public function find($id, $model); 
    public function fetchAll(); 
} 

Dalla mia esperienza manca con questo stile di programmazione , Trovo difficile afferrare l'actua traggo beneficio da quest'ultimo modo; Comprendo che questo metodo separa il più possibile il database dalla logica effettiva, che in teoria dovrebbe facilitare la transizione a un'altra piattaforma di database. Tuttavia, davvero non vedo che questo accada su nessun progetto che sto lavorando.

Non c'è quasi dubbio che sto trascurando qualcosa, quindi mi piacerebbe sentire i vostri consigli.

La domanda:

• Qualcuno potrebbe spiegare a me perché (o se) il secondo è meglio pratica?

• dovrei passare dal vecchio modo di nuovo modo o ci sono ancora ragioni legittime per attaccare con modelli che rappresentano le tabelle del database?

Grazie in anticipo.

Answer 1

Ecco la mia spiegazione al motivo per cui questa è una pratica migliore:

Credo che il beneficio vera a questo è la capacità di cambiare senza problemi le origini dati. Aggiungendo un ulteriore livello di astrazione all'applicazione, i modelli non rappresentano più una tabella di database (non dovrebbe mai, a mio avviso) come un modello dovrebbe essere una rappresentazione dei dati (non un gateway). Il livello di accesso al database dovrebbe essere incapsulato dal modello, consentendo una maggiore flessibilità.

Supponiamo, ad esempio, che l'applicazione sia necessaria per iniziare a utilizzare un servizio SOAP o XML-RPC come origine dati/archiviazione. Utilizzando l'approccio del mappatore dei dati, si ha un netto vantaggio, dato che si dispone già della struttura necessaria per aggiungere queste interfacce del livello dati specifiche senza interferenze eccessive (se esistenti) con i modelli esistenti.

Se lo fai, però? Questa è una domanda pragmatica. Personalmente, mi piace avere la tranquillità che sto sviluppando qualcosa che è flessibile e segue (concordato) le migliori pratiche. Tuttavia, solo tu sai se creare un'applicazione più flessibile renderà i tuoi progetti più facili, sia ora che in futuro, da costruire e mantenere.

Per me, mi piace solo la sensazione che sto costruendo qualcosa, che considero la migliore pratica e spesso paga i dividendi.

Answer 2

È utile perché è possibile fare $insert = new Model_Guestbook($param1, $param2, $param3); - significa che quando qualcuno arriva al progetto, può creare facilmente una nuova istanza senza conoscere la struttura del database (controllando l'interfaccia sorgente/per modello). Questo è solo uno dei vantaggi di questo metodo offre :)