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.