in Zend, perché utilizziamo la classe DB Model e la classe Mapper come due separate?

Question

Sto lavorando al progetto Zend, mi riferisco ad altri progetti Zend per creare il nuovo progetto Zend. Ma non mi piace seguire ciecamente quel progetto senza capire. Nella struttura di directory Zend, in classe del modello ci sono principalmente due tipi di classi che vedo, come come in

- models 
    - DbTables 
     - Blog.php //Extends Zend_Db_Table_Abstract 
    - Blog.php  // Contains methods like validate() and save() 
    - BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b) 

Perché questa struttura specifica è seguito? Si tratta di separare la classe Object e la classe del modello Database?

Spiegare per favore.

Answer 1

DataMapper is a design pattern from Patterns of Enterprise Application Architecture.

Il Data Mapper è uno strato di software che separa gli oggetti in memoria dal database. La sua responsabilità è quella di trasferire i dati tra i due e anche di isolarli gli uni dagli altri. Con Data Mapper gli oggetti in memoria non devono nemmeno sapere che c'è un database presente; non hanno bisogno di alcun codice di interfaccia SQL e certamente non conoscono lo schema del database.

La modalità di memorizzazione dei dati in un database relazionale è in genere diversa da come strutturare gli oggetti in memoria. Ad esempio, un oggetto avrà una matrice con altri oggetti, mentre in un database, la tabella avrà invece una chiave esterna ad un'altra tabella. A causa dello object-relational impedance mismatch, si utilizza un livello di mediazione tra l'oggetto dominio e il database. In questo modo, puoi evolvere entrambi senza influenzare l'altro.

Separare la responsabilità di Mapping nel proprio livello è anche più strettamente successivo allo Single Responsibility Principle. I tuoi oggetti non hanno bisogno di conoscere la logica del DB e viceversa. Questo ti dà una maggiore flessibilità quando scrivi il tuo codice.

Quando non si desidera utilizzare un modello di dominio, in genere non è necessario DataMapper. Se le tabelle del tuo database sono semplici, potresti preferire un TableModule e TableDataGateway o anche solo ActiveRecord.

Per vari altri modelli di vedere la mia risposta a

• ORM/DAO/DataMapper/ActiveRecord/TableGateway differences? e
• http://martinfowler.com/eaaCatalog/index.html

Answer 2

L'idea di un modello è quello di concludere la raccolta logica dei dati all'interno del codice.

L'idea di un DataMapper è di mettere in relazione questa raccolta di dati a livello di applicazione con la modalità di archiviazione.

Per molte implementazioni di ActiveRecord, il framework non fornisce questa separazione di intenti e questo può portare a problemi.Ad esempio, un modello BlogPost può avvolgere le informazioni di base di un post come

• titolo
• autore
• corpo
• date_posted

Ma forse anche voi volete averlo contenere qualcosa del tipo:

• numero_di_legati
• number_of_likes

Ora è possibile memorizzare tutti questi dati in una singola tabella MySQL per cominciare, ma come il tuo blog cresce e si diventa super-famoso, si scopre che i dati statistici sta prendendo un sacco di hit e si desidera spostarlo su un server di database separato.

Come procederesti alla migrazione di quei campi degli oggetti BlogPost in un altro archivio dati senza modificare il codice dell'applicazione?

Con DataMapper, è possibile modificare il modo in cui l'oggetto viene salvato nei database e il modo in cui viene caricato dai database. Ciò consente di modificare il meccanismo di archiviazione senza dover modificare la raccolta effettiva di informazioni su cui si basa l'applicazione.