NHibernate e Json: semplice e funzionale
Non nego di aver trascurato un po' il blog in questi ultimi tre mesi; il tanto lavoro e niente vacanze, hanno influito negativamente sulla mia vena creativa.
Nonostante tutto, ancora una volta, un "meraviglioso" lavoro con cui mi sto cimentando in questo periodo é fonte dell'ispirazione di questo post.
Definiamo lo scenario di lavoro: ammettiamo di avere un elenco di elementi, tuttosommato semplici, che posseggono una serie di oggetti collegati. Per fare un esempio calzante, definiamo un certo numero di locazioni geografiche ("GeoLocation"), ciascuna delle quali contiene una lista di risorse ("RemoteResource"). La locazione possiede una serie di attributi (che sono di nessuna rilevanza per la questione), mentre le risorse sono composte solamente da un url assoluto, e una data di registrazione della risorse stessa. Normalmente, per la persistenza dei dati su un database, si procederebbe alla creazione di una tabella per le locazioni ("GeoLocations"), ed una separata per le risorse ("RemoteResources"); ciascuna di queste ultime, oltre ai campi "Url" e "RegistrationDate", avrà poi una chiave esterna alla specifica locazione di riferimento. Ma ammettiamo di essere un situazione in cui non è necessario che siano eseguite delle particolare ricerche sulla base degli attributi di "RemoteResource": tutti gli ordinamenti e le proiezioni sono alla base della sola "GeoLocation". La lista di risorse, a tutti gli effetti, è un attributo "fisso" della locazione; e allora, perchè non trattarlo come tale e permettere che una "GeoLocation" sia persistita sulla base dati come entità atomica? Perchè, quando eseguo un'operazione di salvataggio o di caricamento, non posso ottenere con un singolo "round trip" sulla base dati tutte le informazioni "auto-consistenti" di una entità geografica?
Certo, la prima possibilità per fare questo, con la struttura di archiviazione definita, è quella di procedere con un semplice "join" sulle due tabelle sorgenti. Ma diciamo che vogliamo trattare il modello "GeoLocation" come un grafo, un documento, che contiene tutte le informazioni per definire se stesso nel dominio dati come entità unica ed inscindibile.
Per fare ciò, l'unica possibile soluzione è predisporre un campo della nostra tabella "GeoLocations" ad ospitare i dati della lista di "RemoteResource" collegate alla locazione stessa: un banale "NVARCHAR(MAX)" (in SQL Server) o un type di analoghe caratteristiche.
Il dato deve essere poi, in qualche modo, trasformato in un formato dal quale sia possibile eseguire la smaterializzazione/rimaterializzazione dei modelli delle risorse remote, in maniera semplice, rapida e senza alcuna perdita di informazione. Il formato più consono allo scopo (e il più compatto) è sicuramente JSON (Javascript Object Notation), e lo strumento per realizzare questa operazione di conversione è la libreria open source Json.Net.
Ma procediamo con ordine. La mappatura di NHibernate dell'entità "GeoLocation" non è niente di più che il solito file XML dichiarato come Embedded Resource, all'interno del quale il campo che sarà adibito al contenimento dei nostri dati serializzati, è opportunamente caratterizzato da un "type" custom. Tutta la "magia" si nasconde nell'implementazione dell'interfaccia "IUserType", che opportunamente combinata con le funzioni di serializzazione di Json.Net, permette di "insegnare" ad NHibernate come trattare un oggetto particolare, che altrimenti non sarebbe in grado di gestire.
L'implementazione del custom type è tutt'altro che semplice da illustrare. In rete si trovano decine di tutorial ed articoli che trattano la tematica nel dettaglio, ed illustrano con rara precisione ogni singola sua peculiarità; ma a me interessa condividere questa particolare applicazione...nel prossimo post.
Alla prossima...
M.
Nonostante tutto, ancora una volta, un "meraviglioso" lavoro con cui mi sto cimentando in questo periodo é fonte dell'ispirazione di questo post.
Definiamo lo scenario di lavoro: ammettiamo di avere un elenco di elementi, tuttosommato semplici, che posseggono una serie di oggetti collegati. Per fare un esempio calzante, definiamo un certo numero di locazioni geografiche ("GeoLocation"), ciascuna delle quali contiene una lista di risorse ("RemoteResource"). La locazione possiede una serie di attributi (che sono di nessuna rilevanza per la questione), mentre le risorse sono composte solamente da un url assoluto, e una data di registrazione della risorse stessa. Normalmente, per la persistenza dei dati su un database, si procederebbe alla creazione di una tabella per le locazioni ("GeoLocations"), ed una separata per le risorse ("RemoteResources"); ciascuna di queste ultime, oltre ai campi "Url" e "RegistrationDate", avrà poi una chiave esterna alla specifica locazione di riferimento. Ma ammettiamo di essere un situazione in cui non è necessario che siano eseguite delle particolare ricerche sulla base degli attributi di "RemoteResource": tutti gli ordinamenti e le proiezioni sono alla base della sola "GeoLocation". La lista di risorse, a tutti gli effetti, è un attributo "fisso" della locazione; e allora, perchè non trattarlo come tale e permettere che una "GeoLocation" sia persistita sulla base dati come entità atomica? Perchè, quando eseguo un'operazione di salvataggio o di caricamento, non posso ottenere con un singolo "round trip" sulla base dati tutte le informazioni "auto-consistenti" di una entità geografica?
Certo, la prima possibilità per fare questo, con la struttura di archiviazione definita, è quella di procedere con un semplice "join" sulle due tabelle sorgenti. Ma diciamo che vogliamo trattare il modello "GeoLocation" come un grafo, un documento, che contiene tutte le informazioni per definire se stesso nel dominio dati come entità unica ed inscindibile.
Per fare ciò, l'unica possibile soluzione è predisporre un campo della nostra tabella "GeoLocations" ad ospitare i dati della lista di "RemoteResource" collegate alla locazione stessa: un banale "NVARCHAR(MAX)" (in SQL Server) o un type di analoghe caratteristiche.
Il dato deve essere poi, in qualche modo, trasformato in un formato dal quale sia possibile eseguire la smaterializzazione/rimaterializzazione dei modelli delle risorse remote, in maniera semplice, rapida e senza alcuna perdita di informazione. Il formato più consono allo scopo (e il più compatto) è sicuramente JSON (Javascript Object Notation), e lo strumento per realizzare questa operazione di conversione è la libreria open source Json.Net.
Ma procediamo con ordine. La mappatura di NHibernate dell'entità "GeoLocation" non è niente di più che il solito file XML dichiarato come Embedded Resource, all'interno del quale il campo che sarà adibito al contenimento dei nostri dati serializzati, è opportunamente caratterizzato da un "type" custom. Tutta la "magia" si nasconde nell'implementazione dell'interfaccia "IUserType", che opportunamente combinata con le funzioni di serializzazione di Json.Net, permette di "insegnare" ad NHibernate come trattare un oggetto particolare, che altrimenti non sarebbe in grado di gestire.
L'implementazione del custom type è tutt'altro che semplice da illustrare. In rete si trovano decine di tutorial ed articoli che trattano la tematica nel dettaglio, ed illustrano con rara precisione ogni singola sua peculiarità; ma a me interessa condividere questa particolare applicazione...nel prossimo post.
Alla prossima...
M.
Commenti
Posta un commento