Nei capitoli precedenti abbiamo visto che l’accesso ai dati del database avviene tramite query SQL che restituiscono recordset, mentre la modifica degli stessi avviene tramite l’esecuzione di comandi SQL.
Questa modalità è efficace soprattutto quando si devono estrarre dal database situazioni riassuntive, che richiedono la costruzione di query complesse con molti join tra tabelle. In molti altri casi, invece, l’uso di SQL e recordset porta ad una minore efficienza del ciclo di sviluppo perché non permette di operare sui dati in modalità Object Oriented. Per ovviare a questo problema si utilizza la tecnica Object Relational Mapping.
La difficoltà accennata prima viene accentuata quando i dati su cui operare sono complessi, cioè derivano dalla composizione di dati semplici. Ad esempio, nella seguente struttura dati possiamo evidenziare tre tabelle:
- Orders: contiene i dati di testata degli ordini di acquisto.
- Order Details: contiene i dati degli articoli venduti in ogni ordine.
- Products: contiene l’elenco dei prodotti che è possibile vendere.
Fra queste tabelle esistono anche delle relazioni. In particolare fra Orders e OrderDetails esiste una relazione che collega ogni riga di un ordine alla sua testata; essa esprime un concetto di possesso: ogni testata ordine possiede le sue righe; se una testata venisse eliminata, anche le relative righe dovrebbero subire la medesima sorte.
Anche fra Products e OrderDetails esiste una relazione, che esprime un concetto diverso: ogni riga ha bisogno di identificare il prodotto venduto, quindi la relazione non è possessiva, ma identificativa. Se infatti una riga d’ordine venisse eliminata, il prodotto relativo rimarrebbe intatto. Se invece si volesse eliminare dal database un prodotto che è stato venduto, tale operazione dovrebbe essere impedita per preservare il legame con le righe degli ordini in cui esso è stato venduto.
Qual è il modo più immediato per lavorare su strutture dati di questo genere? Mappare tali strutture su una gerarchia di classi con cui lavorare in modalità object oriented. Nell’esempio precedente potremmo avere tre classi:
- La classe Order che gestisce un intero ordine (testata e righe).
- La classe Order Detail che gestisce una riga di un ordine.
- La classe Product che gestisce un prodotto.
Potremmo gestire anche le relative relazioni: un’istanza di Order deve poter gestire anche le proprie righe, quindi la classe Order avrà una proprietà di tipo Collection per contenerle. Una istanza di Order Detail avrà bisogno di accedere ai dati del prodotto a cui essa si riferisce; in questo caso dovrà avere un metodo da richiamare per ottenerlo. Schematicamente potremmo avere la seguente gerarchia di classi:
Il framework Document Orientation (DO) di Instant Developer Cloud nasce proprio per rendere possibile lavorare sui dati presenti nel database relazionale in modalità object oriented.
Ma perché Document Orientation? Il nome deriva da un’accezione del termine documento che è propria di questo framework. La definizione del termine documento nell’ambito del framework DO è pertanto di fondamentale importanza per la comprensione del suo funzionamento.
I documenti sono classi JavaScript in cui vengono mappate le tabelle di un database e che ne gestiscono i record. Un’istanza di queste classi è chiamata documento. I documenti possono mappare le relazioni possessive tra le tabelle del database tramite collection, e possono quindi gestire strutture multilivello. Tramite i documenti è quindi possibile rappresentare qualunque documento gestionale delle proprie applicazioni.
Il framework DO prende in carico la gestione del caricamento e salvataggio dei dati nel database non record per record, ma dell’intera struttura multilivello. Gestisce inoltre il ciclo di vita dei documenti, facilita il collegamento con il front-end e consente la sincronizzazione dati tra dispositivi e backend cloud.
Per queste ragioni, i documenti sono un componente fondamentale di ogni progetto Instant Developer Cloud.