Persistenza Presente e Futuro

Nello sviluppo di un nuovo applicativo si devono considerare un insieme di cose:
1. Il flusso logico
2. La rappresentazione dei dati
3. La memorizzazione dei dati
La programmazione ad oggetti semplifica molto i 3 passaggi ma richiede una forte progettualità. Inoltre all'atto della memorizzazione dei dati sorge il problema di prelevare i dati dagli oggetti, inserirli all'interno di tabelle del database e salvarli. Il processo inverso è evidentemente altrettanto complesso (leggere i dati dalle tabelle e ricreare gli oggetti in maniera opportuna).
I DBMS hanno una grande storia alle spalle e sono il modo più performante per gestire grosse moli di dati (grazie a SQL, stored procedure ed altro).
D'altro canto gli oggetti sono il modo migliore di gestire progetti di certe dimensioni nonchè per posizionare la logica applicativa in maniera corretta all'interno delle entità interessate.Le soluzioni proposte oggi per "fondere" i 2 punti di vista (di memorizzazione ed elaborativo) cercano di portare la memorizzazione dei dati nel DBMS il più vicino possibile alla rappresentazione in memoria dei dati stessi (relazione tra gli oggetti).
In particolare tra i framework (OR-Mapping):
- ECO framework per chi usa Borland Developer Studio (Delphi .NET e C#)
- Instant Object per chi usa Delphi per Win32
- Hibernate ed EJB per chi usa Java
Il principio su cui si basano è quello di frapporre uno strato SW tra il DBMS e la struttura ad oggetti, consentendo operazioni quali il recupero dell'oggetto direttamente dal DBMS ed il salvataggio di oggetti tra loro correlati.
Tra i Database (ODBMS):
- Matisse (è l'unico che ho provato)
Il principio su cui si basano è quello di esporre all'esterno Oggetti che si possono assegnare a variabili oggetto.

Un altro sistema di memorizzazione dei dati offerto dai framework ad oggetti è la persistenza degli stessi: in pratica gli oggetti possono salvarsi su files direttamente portandosi dietro tutti gli oggetti eventualmente riferiti. Questo meccanismo è il più orientato alla programmazione ed il meno orientato ai dati: lo stream di oggetti salvato su file non può essere consultato dall'esterno e non può essere aperto se non da chi ha progettato la struttura degli oggetti.

Insomma i DBMS devono rimanere perchè sono molto performanti; gli oggetti devono continuare ad esistere come metodologia di programmazione. Resta il problema di rendere la rappresentazione ad oggetti sul Database "chiara" per poter effettuare reports e query usando SQL.
Il futuro?
Microsoft sta lavorando ad un nuovo progetto LINQ Language Integrated Query per rendere uniforme il reperimento dati tra DBMS e collezioni di oggetti.
Staremo a vedere.