Ok, sembra che il corso di settimana scorsa sia piaciuto e che, per l'ennesima volta, il tempo non sia stato sufficiente, giacchè Alessio avrebbe gradito un approfondimento sul tema "Query Object". Provo a "rimediare" :-)
In realtà la richiesta di Alessio sottointende 3 distinte tematiche:
- "Query Object": chi era costui?
- Implementazione "hand made" di un DAL capace di gestire in maniera sensata la persistenza di un DM
- Produzione "al volo" del codice SQL
Andiamo in ordine: il design pattern query object è una specializzazione di Interpreter che si pone l'obbiettivo di definire un object model in grado di rappresentare una query SQL. Ciò significa, in pratica, permettere ad un sistema di produrre a runtime un grafo che definisca una query che il DAL si preoccuperà di eseguire restituendone il risultato. "Sbarazzandosi" da un punto di vista logico di SQL, il nostro sistema guadagna potenzialmente l'indipendenza da uno specifico RDBMS o, volendo estremizzare, da una specifica tecnologia/architettura di persistenza. Esempi di query object sono la Criteria API di (N)Hibernate o, se volete un esempio più semplice, il query model di NSK che è stato espressamente pensato per risultare "digeribile", pur rununciando all'obbiettivo di poter rappresentare il 100% delle query. Infine, LINQ è *il* query model idiomatico offerto dai compilatori "2008" di C# e VB (ricordiamo che un "idioma" è un omologo "technology specific" di un design pattern)
Disporre di un query model è però solo l'inizio, poichè occorre "qualcuno" in grado di eseguirlo: questo "qualcuno" è il DAL. E qui le strade sono fondamentalmente 2: a valle del parsing del grafo ottenuto istanziando il "query object", il codice SQL lo scriviamo noi o cerchiamo di produrlo "al volo".
Nel primo caso, indipendentemene dal fatto che SQL sia "embedded" nella applicazione o "confinato" nelle stored procedure, ci si accorge presto che, usando un DM, il DAL dovrebbe offrire servizi quali: gestione della concorrenza, lazy load...
La soluzione è "semplice" e consiste nel creare dei proxy per le classi del DM: Markino ha bloggato già in passato (oddio, sono già passati oltre due anni... sto invecchiando!!!!) la strategia che usiamo in Managed Designs per produrre i proxy, e che è possibile osservare maggiormente in dettaglio analizzando il sorgente del DAL "SQL Server" di NSK: in sintesi, si tratta di definire i proxy come classi internal al DAL effettuando l'override degli opportuni membri del DM e/o estendendo opportunamente quest'ultimo (per esempio, per la gestione del lock ove si usino gli "original value" e non un timestamp/numero di versione della riga).
Infine... Arriviamo al "punto 3": produrre codice SQL "al volo". Nell'ultimo anno ho dovuto implementare un O/RM "custom" a causa di un requisito non funzionale (ergo, il cliente chiedeva che l'applicazione usasse *esclusivamente* il FX 2.0 e quindi "nisba NHibernate o librerie esterne"): oltretutto, mi occorrevano feature che ad oggi nemmeno NH offre, quali il mapping di entità "frammentate" (presente in NH 2 ma non in 1.2, ossia l'ultima release GA) o la possibilità di mappare il DM su database differenti (nel senso che pezzi distinti dello stesso grafo provengono da db differenti), con tutte le immaginabili conseguenze a livello di distribuzione delle transazioni in fase di persistenza.
Non ho dubbi nell'affermare che sia stata una delle sfide maggiormente probanti della mia "carriera professionale" e che mi ha permesso di comprendere molto più profondamente il mondo degli O/RM rispetto a quando ero "solo" un "utente" di NH e Genome. Ad aver tempo da "perdere", è un esperienza che consiglierei a tutti <g>
Ecco, il punto 3 è un po' troppo complesso per pensare di trattarlo in un post "mattone" come questo: è il motivo per il quale ho aggiunto la sessione "O/RM Inside Out" nella agenda dei Community Days 2008. Sarà una sessione praticamente "slide free" e nella quale approcceremo il mondo degli O/RM da un punto di vista differente da quello tipicamente adottato nelle sessioni dedicate a questo argomento: vi assicuro che, anche come "utenti", "dopo" non saremo più gli stessi :-)