Ultimamente mi stò concentrando a studiare il design di applicazioni che fanno accesso ai dati, le architetture ricorrenti, i tool a disposizione, i relativi pattern.
Quindi ho deciso di pubblicare un punto fermo di quanto raggiunto finora.
Sono giunto alla conclusione che il mondo relazionale ed il mondo ad oggetti non siano conciliabili: il problema risiede nelle scopo per cui sono stati concepiti.
Il modello relazionale pone l'accento sulla organizzazione dei dati. Il modello ad oggetti apparentemente fa una cosa simile tramite le gerarchie di oggetti. In realtà il primo è molto più ricco di informazioni poichè "dichiara" esplicitamente relazioni tra collezioni di oggetti, mentre il secondo costruisce un sistema "rigido" che lega singole istanze di oggetti. Un tipico approccio nella realizzazione di una applicazione prevede la necessità di garantire la persistenza ad entità individuate durante la modellazione del sistema. Ovviamente qualora la necessità fosse esattamente questa, l'utilizzo di un buon tool di mapping può essere sufficiente allo scopo e garantire quanto richiesto.
L'attività di "trasbordare" i dati dal mondo relazionale a quello ad oggetti può essere visualizzata come una proiezione (in maniera simile al disegno tecnico).
La ricchezza del modello relazionale si evidenzia nella possibilità di richiedere al sistema di trovare la soluzione a dei sistemi di equazioni che noi sintetiziamo con una query sql.
I modelli ad oggetti, non disponendo di questa ricchezza di informazioni non sono in grado di rispondere alle stesse interrogazioni. Qualcosa si può fare per "dedurre" queste informazioni...
In pratica ai miei occhi appare evidente la somiglianza tra la modalità di utilizzo di sistemi ad oggetti ed i database gerarchici (tipo DLI per intenderci...). La costruzione di ambedue i sistemi consente di navigare relazioni di tipo padre-figlio, poichè l'unico modo per raggiungerne uno è passare attraverso il padre. Ne deriva che ogni esigenza di interrogazione del sistema deve essere prevista a priori ed implementata "proceduralmente" ad-hoc. Proprio la contrapposizione tra "dichiara" e "proceduralmente" evidenzia la differenza concettuale dei due modi di organizzare ed utilizzare le informazioni.
In un mondo che va verso un approccio dichiarativo, non possiamo proprio cambiar rotta, quindi la soluzione non è, a mio avviso, avvicinare il modello relazionale a quello ad oggetti, ma, al contrario, far propri del secondo alcuni meccanismi del primo.
Il mondo ad oggetti è piatto mentre quello relazionale è multidimensionale...
Un'altra "evidenza sperimentale" della validità delle mie osservazioni mi par di rilevarla nell'altro modo di conservare le informazioni che va per la maggiore oggi: i documenti xml.
I modi per elaborare le informazioni contenute in un documento xml sono, sostanzialmente, due: interrogazione via XQuery (XPath) e trasformazione procedurale tramite XSLT (anche se qui occorre distinguere lo stile di utilizzo dei template) che poi equivale ad accedere via DOM. Mentre il primo sfrutta la struttura del documento per trovare le informazioni richieste (analogia con SQL), il secondo per ogni nodo che soddisfa i criteri di selezione del template corrente, esegue il template successivo. Anche qui approccio dichiarativo contro quello procedurale.
Queste dunque le mie conclusioni.
Nel mondo Java (J2EE) esiste lo stesso concetto di query di oggetti (Entity Bean) tramite il linguaggio Enterprise JavaBeans Query Language (EJB QL), nell'architettura CORBA gli object broker grazie a Object Query Language (OQL), perchè non applicare qualcosa di simile al di fuori del contesto di un application server? Quello che serve è un modo per interrogare gli oggetti e le relazioni (i riferimenti) tra gli oggetti "vivi" all'interno della VM (.NET o Java). E' chiaro che il garbage collector sa tutto della gestione della memoria e quindi degli oggetti e dei tipi, quindi si potrebbe (dico forse poichè non ho la più pallida idea di quanto sia opaca quella parte dei framework al codice applicativo) sfruttare quella "base di conoscenza" allo scopo.
Una alternativa che mi piacerebbe di più, dato che ci si vincolerebbe ai dettagli implementativi delle VM (per non citare il rischio di interagirvi) sarebbe sfruttare un approccio AOP e definire dei meccanismi di raccolta delle informazioni sugli oggetti ogni qualvolta vengono creati, passati per riferimento, distrutti (pointcut). In modo particolare ottenere dei riferimenti agli oggetti ed ai relativi tipi (evitando la reflection all'atto dell'interrogazione) in dizionari consultabili con qualcosa del tipo:
...
struct resultSetItem { MyType1 a, MyType2 b }
ObjectBroker pippo = new ObjectBroker();
pippo.query = "select * from objects a as MyType1, b as MyType2 where a.orderID = b.orderID";
resultSetItem[] = pippo.execute();
...
L'approccio AOP evita di dover far sapere alle singole classi l'esistenza di questo framework che li gestisce (insomma niente attributi), tuttavia consentirebbe di avere a disposizione un formidabile strumento dentro le applicazioni.
Per adesso è tutto.