Da tabella a classe

Ciao Gianni

guardando ROR ho notato che si usa spesso avere una classe che contiene i valori di una tabella del database, una cosa del genere:

tabella nel db:

books:

id

nome

autore

editore

classe books

id

nome

autore

editore

metodi:

load

insert

update

delete

delete_all

Cosa comporta avere il db in una classe?

Quali sono i vantaggi offerti da questa soluzione e quali gli svantaggi?

Ad esempio è vantaggioso anche quando si ha a che fare con grandi quantità di record?

Una sola istanza della classe contiene un singolo record?

:bye:

inviato 9 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

Non basterebbe un libro per rispondere a questa domanda...

Iniziamo col dire che nella progettazione del software nasce prima la classe e poi la tabella. Questo perché l'ingegneria del software applicata alla programmazione ad oggetti ha definito un percorso nella realizzazione del software che prevede dei passi ben precisi. L'analisi, ovvero la progettazione, parte dallo studio del "dominio" ovvero dal mini-mondo sul quale il software va ad agire. In qiesto mini-mondo vanno individuate le "entità" (utente, prodotto, fattura, magazzino, ecc.) che vengono astratte e trasformate in classi, dette classi di business. Data la natura di queste classi la maggior parte di esse richiede persistenza, ovvero deve essere possibile conservarne le istanze (gli oggetti) e la persistenza viene realizzata quasi sempre attraverso un database.

Si procede quindi a creare un modello relazionale partendo dal modello ad oggetti e questa operazione avviene attraverso una mappatura classi-tabelle che si ottiene con delle tecniche che vanno sotto il nome di ORM (Object relational mapping). Per questo motivo i programmi ad oggetti spesso hanno un insieme di classi che rispecchia le tabelle del DB.

Ma questo è solo un lato della medaglia. Va detto infatti che spesso nasce prima il database e poi il software  per cui il discorso suddetto è difficilmente applicabile. Inoltre spesso una applicazione ad oggetti deve gestire dei dati provenienti da DB (che non necessariamente appartengono a classi di business) e non essendo questi degli oggetti ma dei "record" risultano indigesti al linguaggio stesso. Pensa a quei linguaggi come il Java dove a parte i tipi di dati primitivi tutto il resto è un oggetto (anche una stringa!).

In questi casi trasformare il singolo record di una tabella oppure un insieme di record in oggetti è una esigenza più tecnica che progettuale. E siccome in questi linguaggi così fortemente orientati agli oggetti si tende sempre ad adottare dei pattern di progettazione (design patter) allora si finisce sempre con abbracciare uno degli approcci standardizzati.

Per quanto riguarda la rappresentazione di un record di un DB in un oggetto ci sono 2 patter principali:

Active Record: si tratta di un oggetto che contiene i dati del record del DB ed in più tutta la logica applicativa per gestire la sua persistenza ed interfacciarsi con il DB stesso. L'esempio che mi hai fatto è proprio un Active Record.

Table Data Gateway e Row Data Gateway: questi approcci prevedono la separazione dei compiti di conservazione dei dati e gestione degli stessi in 2 classi distinte. Una classe si limita ad avere gli attributi che rispecchiano i campi del DB mentre un'altra (o più di una) gestisce il suo interfacciamento con il DB pechè possiede i metodi di inserimento, modifica, cancellazione e selezione.

Veniamo ora alle tue domande:

Cosa comporta avere il db in una classe?

Di per se nulla, poiché in realtà il DB rimane dov'è. In pratica vengono solo riorganizzate le cose (dati e funzioni) che avresti comunque realizzato.

Quali sono i vantaggi offerti da questa soluzione e quali gli svantaggi?

A volte è necessario procedere in questo modo se il linguaggio è fortemente ad oggetti. Se tutto deve essere un oggetto allora facciamo in modo che sia comodo da usare...

Se non si è costretti ma comunque si è scelto di progettare il software secondo il paradigma ad oggetti allora  non ci si può tirare indietro proprio alla fine. E' evidente che la complessità aumenta rispetto al normale approccio procedurale ma questo lo sapevamo già: la programmazione ad oggetti è più complessa!

Ad esempio è vantaggioso anche quando si ha a che fare con grandi quantità di record?

Se ci pensi bene il volume dei dati in una applicazione rimane lo stesso, sia se usi un array di 50 record sia se usi 50 oggetti. E' vero che il PHP è più veloce nel gestire un array rispetto ad un oggetto ma questo è un problema del linguaggio e con tempo verrà minimizzato

Una sola istanza della classe contiene un singolo record?

Dipende dal pattern adottato. Ad esempio il Table Data Gateway e Row Data Gateway si basano sul costruire una classe che funge da Gateway che si frappone tra il DB e l'applicazione. A questa classe viene chiesto di prelevare o conservare oggetti da e verso il database. Ciascuno degli oggetti restituiti da queste classi Gateway rappresenta un record del DB.

Spero di non averti confuso le idee...

 :bye:

risposto 9 anni fa
Gianni Tomasicchio
X 0 X

No,anzi ti ringrazio :D per avermi spiegato :)

Non volevo dire che "mettere il db in un oggetto o una classe" :D lol ... :2funny: ma a quanto pare hai capito ugualmente :D cosa intendevo dire.

ultimamente sto trovando interessante lo studio delle patterns :P ( applicate in java ) e mi sto avvicinando sempre più ( ancora sono mooolto distante da una vera conoscenza sull'argomento) alla progettazione del software piuttosto che l'implementazione diretta :P

PS : Zend framework ha active record o qualcosa di simile?

:bye:

risposto 9 anni fa
Andrea Turso
Andrea Turso
86
modificato 9 anni fa
X 0 X

Zend Framework utilizza Table Data Gateway e Row Data Gateway per le classi Zend_Db_Table, Zend_Db_Table_Rowset e Zend_Db_Table_Row

 :bye:

risposto 9 anni fa
Gianni Tomasicchio
X 0 X
Effettua l'accesso o registrati per rispondere a questa domanda