Chiunque abbia fatto un po’ di programmazione ad
oggetti sa benissimo che le difficoltà più grandi si affrontano quando si deve gestire la
persitenza delle informazioni.
Questo perché il nostro modello ad oggetti deve essere salvato su un database che nella totalità dei casi è un
database relazionale. Cioè fatto di tabelle piatte su cui salvare i dati. Questo porta ad una dicotomia (
impedance mismatch): da una parte il modello usato dai programmi applicativi dovrebbe essere quanto più ad oggetti, dall’altra il modello deii dati sul database deve essere puramente relazionale.
Il problema viene risolto in vari
modi: si può sacrificare il modello ad oggetti alla logica del database, individuando come oggetti le tabelle dove andranno a salvarsi i dati oppure si può utilizzare uno strato di software che si occupa di fare la conversione tra i due modelli.
Entrambi i metodi hanno, chiaramente, degli svantaggi, sia dal punto di vista delle performance, sia dal punto di vista della manutenibilità del codice e della sua chiarezza.
Una soluzione, che già era stata percorsa una decina di anni fa con scarsi risultati, è quella di avere dei database ad oggetti, che salvano gli oggetti mantenendone le caratteristiche.
Uno di questi è
db4o (db for objects), che è rilasciato mediante
GPL per scopi non commerciali (una licenza uguale a quella di
MySQL). Scritto in versione
java e
.NET, fornisce al programmatore delle semplici API che consentono di salvare oggetti complessi direttamente con una istruzione.
Certo si perde tutto l’SQL, la teoria sulle normalizzazioni e gli
RDBMS, ma ci si può fare un pensierino per modelli ad oggetti di una certa complessità.
Qui e
qui approfondimenti sul tema.
Dottori, non preoccupatevi, sto bene (si fa per dire, naturalmente), è che volevo un po’ fare il
Beggi, oppure il
Fullo.
