Crad's .NET Blog

Alle volte (anzi, molto spesso) nel realizzare la nostra applicazione non abbiamo tutta la libertà di questo mondo, magari perché lo schema DB ci viene "imposto" da un'altra figura professionale. In questi casi non è raro trovarsi ad avere a che fare con chiavi primarie composte, che si estendono cioé su più colonne. Con NHibernate possiamo gestire egregiamente anche situazioni di questo tipo, anche se è bene sottolineare che le cose si complicano un pochino quindi, nel caso in cui si debba partire da zero, è sempre meglio utilizzare la solita surrogate key, semplice, invariante e priva di significato.

Bene, supponiamo di avere il seguente schema:

concentriamoci per il momento esclusivamente sull'oggetto fattura. In prima approssimazione, una sua semplice rappresentazione nel domain model potrebbe essere del tipo:

NHibernate, come sappiamo, identifica gli oggetti grazie al loro identityField. Affinché tutto continui a funzionare anche nel caso in cui esso non sia uno scalare, ma un tipo complesso, è necessario effettuare l'override dei metodi Equals() e GetHashCode(); in caso contrario, infatti, l'engine di persistenza non sarebbe in grado di determinare quando due oggetti si riferiscono alla medesima riga di database (e quindi, ad es., gestire correttamente l'identity map della sessione, dato che questo altri non è che un dictionary). Allora, per isolare il concetto di id della fattura dalla fattura stessa, può essere conveniente creare una classe ad-hoc:

Una piccola nota: è di estrema importanza ridefinire correttamente anche GetHashCode(), e per correttamente intendo dire "in modo coerente a Equals", cioé che due oggetti uguali restituiscano hash uguali, mentre due oggetti diversi restituiscano hash diversi. A volte mi è capitato di vedere

Bene, sappiate che quanto scritto qui sopra è il modo migliore per far sì che subdoli bachi intervengano a turbare le vostre notti.

Torniamo a noi. Come scriviamo il mapping di un domain del genere? IdFattura per NHibernate non è una entity, bensì un component, vale a dire un value type (attenzione, non nel senso di .Net) il cui lifetime coincide con quello della entity a cui esso è collegato e che ha senso solo quando collegato alla entity stessa. Definizione e mapping sulle colonne, pertanto, si trovano all'interno del nodo class della entity Fattura:

Nonostante l'oggetto Session sia privo di eventi, NHibernate offre comunque un supporto a chi voglia realizzare dei metodi di Callback implementando il pattern Observer tramite un oggetto particolare denominato Interceptor. Esso non è altro che una classe che implementa l'interfaccia IInterceptor, la quale espone alcuni metodi che vengono richiamati dalla Session in corrispondenza delle operazioni di Load, Save, Flush, ecc... L'associazione di un Interceptor ad una Session avviene all'atto della sua creazione, tramite un particolare overload del metodo SessionFactory.CreateSession :

Come potrete immaginare, un oggetto del genere si presta ad innumerevoli applicazioni pratiche, una delle quali (diciamo anche quella che più facilmente viene in mente) è la realizzazione di un servizio di audit, che tenga traccia di data e utente relativi alla creazione e alla modifica di un oggetto del nostro dominio. Per far ciò, definiamo innanzitutto la seguente interfaccia:

Tramite NHibernate è possibile persistere automaticamente queste informazioni in ogni classe che implementi questa interfaccia, senza preoccuparcene minimamente all'interno del codice di business.

Il modo più elegante per riuscirci è realizzare una classe che implementi IInterceptor o, più semplicemente, ereditare dalla classe EmptyInterceptor (che altri non è che un Interceptor completamente vuoto), effettuando l'override dei metodi utili al nostro scopo. OnFlushDirty, ad esempio, è sicuramente uno di questi:

Esso viene invocato in corrispondenza del Flush di ogni entity marcata come dirty (cioé che ha subito modifiche dall'operazione di load) e fornisce una serie di parametri per accedere ad una reference alla stessa, conoscerne il suo stato precendente ed eventualmente apportarvi variazioni prima dell'update (agendo sull'array currentState, entity e previousState non dovrebbero mai essere modificati direttamente).

Nel nostro caso, ad esempio, si può scrivere:

Dopo aver verificato che la entity corrente implementi l'interfaccia IAuditable, scorriamo l'array propertyNames alla ricerca delle proprietà "DataModifica" e "UtenteModifica". Una volta trovate, modifichiamo il corrispondente valore nell'array currentState ed impostiamo il valore da restituire a true. Così facendo, NHibernate rifletterà tali modifiche tanto nell'oggetto in memoria che nella query che sarà inviata al database. Una cosa importante da notare è che ciò è possibile nonostante le proprietà di IAuditable siano marcate come Readonly: avendo infatti scritto nel file di mapping

sarà NH stesso a preoccuparsi di utilizzare la strategy selezionata e quindi di utilizzare i corrispondenti fields.

Ovviamente l''interfaccia IInterceptor mette a disposizione parecchi altri metodi per personalizzare il comportamento standard di NHibernate e plasmarlo secondo le nostre esigenze; alcuni di essi sono molto interessanti, parlo ad esempio di

• FindDirty, che permette di determinare se una entity è da considerarsi dirty o meno, in modo che NHibernate possa eventualmente effettuarne la query di update in fase di flush;
• Instantiate, che consente di costruire "a mano" una nuova istanza di un'oggetto dopo che i dati ad esso associati siano stati recuperati dal database;
• IsUnsaved, che lascia all'utente la facoltà di discriminare, in corrispondenza di un SaveOrUpdate, se una entity è transiente o detached, in modo da eseguire rispettivamente una Save o una Update.

Nel mio caso, proprio quest'ultimo è stato di notevole aiuto per risolvere una problematica relativa all'utilizzo di chiavi primarie di tipo assigned, per le quali cioé non è possibile stabilire un unsaved-value, ma scriverò prossimamente un post specifico a riguardo. Purtroppo la documentazione sull'interceptor è piuttosto scarna, sia nella reference di NHibernate che su quella di Hibernate3. Per chi volesse dare un'occhiata approfondita alle API di quest'interfaccia consiglio la Hibernate API Documentation, relativa alla versione 3.1 per Java ma applicabile con un po' d'intuito anche al mondo .NET.

Anche per quest'articolo, come al solito, ho preparato una piccola applicazione d'esempio che può essere scaricata a questo link.

Alla prossima! 

Update: come mi fa giustamente notare Tommaso, EmptyInterceptor non esiste su NHibenate 1.0.2 o, meglio, esiste nel namespace NHibernate.Cfg ma è internal. L'esempio che ho fornito compila perfettamente perché è basato sulla versione 1.2.0 Alpha. BTW, quanto detto in questo articolo continua a valere anche per le versioni precedenti di NHibernate, a patto che si implementi direttamente IInterceptor. Chi volesse realizzare una propria EmptyInterceptor può guardare i sorgenti di NHibernate per avere un'idea del codice (veramente banale) di questo implementor.

powered by IMHO 1.3

Ereditarietà e polimorfismo sono due caratteristiche della programmazione OO estremamente potenti, che possono essere sfruttate anche nella costruzione di domini complessi. La persistenza su un DBMS di queste strutture, però, pone dei problemi, in quanto non sono direttamente mappabili su un modello ER.

Supponiamo di dover persistere su DBMS il seguente dominio:

Come realizzare lo schema del DB? Beh, una trattazione completa dell'argomento è decisamente eccessiva, per cui si rimanda ad altre fonti, a noi basta semplicemente sapere che le scelte più usate ricadono tra:

• Table per class hierarchy, in cui una sola tabella contiene una colonna per ogni attributo di qualsiasi classe della gerarchia, e quindi è capace di contenere tutta la gerarchia di oggetti; i diversi tipi sono distinti dal valore di una particolare colonna, chiamata discriminatore;
• Table per subclass, in cui si crea una tabella per ogni oggetto di qualsiasi livello, le tabelle degli oggetti figlio contengono una FK verso le tabelle relative agli oggetti padre;
• Table per concrete class, in cui si crea una tabella per ogni oggetto figlio, contenente tutte le proprietà dello stesso e dell'oggetto padre.

Il terzo caso pone anche alcune problematiche nel caso in cui esistano delle reference (da tradurre in relazioni su DB) tra altre entity e un oggetto padre (es. Persona -> Veicolo posseduto: sulla tabella Persone che codice metto? ID_Motociclo? ID_Automobile? entrambi?); inoltre, non è direttamente mappabile in NHibernate (lo è su Hibernate per Java dalla versione 3 in poi, credo) e per questa ragione lo trascureremo. Ci concentreremo, allora, sui primi due casi.

Table per class hierarchy

In questo caso è necessario utilizzare nel file di mapping il nodo Discriminator, che accetta un attributo Column per indicare il nome della colonna utilizzata per differenziare i vari tipi. La classe padre (e le classi figlio, mappate tramite l'elemento Subclass), presentano un attributo che indica il valore del discriminatore associato al tipo stesso:

Come si può notare, ovviamente, il nome della tabella è specificato solo nella classe padre. Proviamo ad eseguire del codice e vediamo come reagisce NHibernate. Supponiamo di voler memorizzare una entity:

Come è lecito aspettarsi, NH produrrà una query di inserimento sul DB con il valore del discriminator impostato ad "A", dato che stiamo persistendo un'istanza del tipo Automobile, e con i campi specifici di Motociclo tutti pari a NULL:

Una caratteristica interessante è che possiamo caricare con una Get un generico oggetto di tipo Veicolo, penserà poi NHibernate a costruire, a seconda del discriminator, il tipo concreto corretto. Stesso dicasi se vogliamo recuperare un elenco di veicoli presenti nel database: il metodo ICriteria.List restituirà una IList<Veicolo> con all'interno i tipi concreti memorizzati nel database:

Lo svantaggio di questo approccio è quello di dover creare una tabella su DB per sua natura un po' "sporca", visto che effettivamente memorizza informazioni eterogenee che richiederanno, di volta in volta, di valorizzare alcune colonne piuttosto che altre.

Table per subclass

Per utilizzare il secondo approccio, è necessario modificare leggermente il mapping del dominio, utilizzando l'elemento joined-subclass in luogo del precedente:

NHibernate persisterà le informazioni separatamente, inserendo i valori relativi alle proprietà di ogni classe della gerarchia all'interno della tabella assegnata ed avendo cura che le chiavi primarie coincidano. Lo snippet di codice di creazione di un automobile esposto in precedenza, questa volta produce le seguenti query su DB:

Come si può notare, questa volta la memorizzazione (e lo stesso dicasi per l'eliminazione e per le modifiche che coinvolgono proprietà di entrambi i livelli) richiede l'esecuzione di due query su database, numero che aumenta di pari passo con la profondità della gerarchia.

L'esecuzione di una Get produce invece un output differente, a seconda che si tratti della ricerca di una classe concreta o di una astratta. Se infatti richiediamo una istanza di Motociclo, infatti, NHibernate sa già che per recuperare tutte le informazioni dovrà effettuare un join tra la tabella dei Veicoli e quella dei Motocicli; quindi, lo snippet seguente

Il pattern LazyLoad è quasi sempre utilizzato in NHibernate per il caricamento delle collection di childs in una relazione Master/Detail. Non tutti sanno invece che è possibile applicare questo pattern a tutti i tipi di relazioni, potendo così ottimizzare di molto la dimensione delle query che vengono effettuate su DB e la mole di dati che viene recuperata.

Capita spesso di avere classi con parecchie relazioni Many-To-One, vuoi perché si tratta di classi "dettaglio" di qualcosa, vuoi perché se creo la classe Articolo magari questa espone una proprietà Tipo di tipo (scusate il gioco di parole) TipoArticolo, ecc.ecc... Se non si utilizza il LazyLoad anche per questo tipo di relazioni, NHibernate effettua query con un gran numero di Join che, come sappiamo, possono minare le performance delle applicazioni.

Ho scritto una piccola applicazione di esempio, scaricabile a questo link , che persiste sul DB un Articolo e un TipoArticolo e poi ne forza una lettura. Analizziamo il mapping di Articolo: