Posts by category: NHibernate

by in / Entity Framework / Eventi / NHibernate
No peoples think this is good

Web Congress 3.0: Entity Framework 4.0 vs NHibernate, slide e codice

webcongressVenerdì 16 aprile si è svolto a Pordenone l’evento più importante dell’anno organizzato da 1nn0va sulle tecnologie web.
Quest’anno ho avuto l’onore di farne parte come speaker presentando una sessione sull’accesso ai dati via ORM (Object-Relational Mapping) in un paragone tra il veterano NHibernate ed il promettente Entity Framework 4.0 di Microsoft.

Devo dire che Microsoft ha fatto un gran lavoro per colmare il gap che esisteva tra la prima versione dell’Entity Framework e gli altri protagonisti del settore. Una delle caratteristiche più apprezzate della nuova release è la possibilità ora concreta di utilizzare le proprie classi di dominio senza dover necessariamente ereditare dalla classe base EntityObject. La cosa si fa poi ancora più interessante se sfruttiamo il nuovo sistema di template (T4) che ci permette di generare automaticamente dall’Entity Data model (EDM) le classi di dominio in “modalità” POCO (Plain Old CLR Object).

Per chi fosse interessato in fondo al post trova i link per scaricare le slide e la solution di Visual Studio 2010 con tutto il codice sorgente.

L’applicazione di esempio è un semplice blog engine sviluppato in ASP.NET MVC 2.0 con l’obiettivo di separare per quanto possibile la logica di business dalla presentation e dall’accesso ai dati.

solution L’architettura è a quattro livelli ed in particolare:

  • SampleBlog.Web: progetto di tipo ASP.NET MVC 2.0 ovvero il livello di presentazione dei dati
  • SampleBlog.Model: progetto che astrae la parte Model dell’MVC per slegare la logica di dominio dalla presentazione e che contiene le nostre classi POCO
  • SampleBlog.AppServices un Service-Layer che qui gioca un po’ il ruolo del Repository
  • SampleBlog.CommonPersistence: uno dei tre livelli di persistenza, utilizza ADO.NET “Legacy” quindi SqlCommand, SqlDataReader e stored procedure
  • SampleBlog.NHibernatePersistence: utilizza NHibernate e un mapping su file xml
  • SampleBlog.EntityFrameworkPersistence: utilizza Entity Framework però in versione “Persistence Ignorance”, ovvero mappato sulle classi POCO del nostro modello

Il tutto condito con Windsor il framework IoC di Castle Project che permette di scegliere di volta in volta quale progetto di persistenza usare.

Ricordo comunque che l’applicazione è stata realizzata esclusivamente con l’ottica di mostrare l’accesso ai dati tramite Entity Framework ed NHibernate in contrapposizione a quello che normalmente si fa con ADO.NET “Classic”, non prendetela quindi come esempio di architettura a quattro livelli.

Slide e codice dell’evento disponibili per il download:

/ Read Article /
by in / NHibernate
No peoples think this is good

Eseguire dei filtri nei file xml di mapping in NHibernate con la proprietà where

Immaginiamo di avere una collection di oggetti mappati con un bag in NHibernate e di volerli ottenere già filtrati dal database per una particolare condizione. Sembrerebbe un lavoro da where ed infatti non a caso sfogliando tra gli attributi dell’elemento bag troviamo proprio l’attributo where, ma vediamo in un esempio come utilizzarlo:

/ Read Article /
by in / NHibernate
No peoples think this is good

Come indicizzare una proprietà di un tipo non primitivo in Lucene.Net con un FieldBridge di NHibernate.Search

Può essere utile a volte indicizzare con Lucene.Net una proprietà di un oggetto che non sia una stringa o un tipo primitivo, pensiamo ad esempio alla lista di categorie di un prodotto. Per casi come questo e laddove l’accesso ai dati viene fatto con NHibernate posso raggiungere il risultato desiderato utilizzando un FieldBridge di NHibernate.Search ed un po’ di reflection:

Il FieldBridge permette a NHibernate.Search di indicizzare con Lucene il contenuto di una proprietà qualora non fosse coerente utilizzare il metodo ToString() (quasi mai per i tipi non primitivi). Analizzando il codice sopra riportato si può notare come vengano passati al FieldBridge due parametri: il tipo di oggetto ed il nome della proprietà da indicizzare (righe 38-44). Con questi due parametri ed utilizzando l’utility PropertyReflector (classe di utilità scritta da Guy Mahieu per fare “deep-reflection” di proprietà) viene recuperato il valore da salvare nell’indice di Lucene. Il FieldBridge in oggetto riesce ad indicizzare sia oggetti singoli (righe 31-34) sia collezioni verificandone il tipo ed utilizzando l’interfaccia IEnumerator (righe 11-30). Qui sotto possiamo notare l’utilizzo dell’attributo per una proprietà di tipo IList<T>.

Nota: il PropertyBridge visto in questo esempio nasce da una esigenza specifica e per questo motivo non ricopre tutte le casistiche possibili.

/ Read Article /
by in / NHibernate
No peoples think this is good

Lucene.Net: indicizzare nullable date con un FieldBridge custom

L’altro giorno mi è capitato di dover effettuare con Lucene delle ricerche per un intervallo di date (data inizio e data fine). Siccome le date in questione potevano essere nulle si poneva il problema di come indicizzarle perchè fossero confrontabili con i valori forniti dalla ricerca (esempio minore di e maggiore di…).

Non potendo rinunciare al valore nullo sul database ho pensato di intervenire al momento dell’indicizzazione dell’entità andando a sostituire il valore nullo con un valore di default che fosse uguale al valore minimo di DateTime per la data di inizio e al valore massimo di DateTime per la data di fine.

Avvalendomi dell’aiuto di NHibernate.Search ho realizzato un FieldBridge custom che potesse intervenire nel momento dell’indicizzazione della mia entità. Un FieldBridge non è altro che un “codec” da object a string che consente di indicizzare il contenuto di una proprietà (Object To String) e di recuperarne il valore originale dall’indice (String To Object). Ecco il codice:

Per utilizzare questo FieldBridge è sufficiente decorare con un attributo la proprietà di tipo DateTime che si vuole indicizzare come nell’esempio di codice seguente:

/ Read Article /
by in / NHibernate
No peoples think this is good

Could not find dialect in configuration

In questi giorni ho avuto l’occasione di utilizzare l’ultima build di Castle Project. Utilizzando ActiveRecord mi sono però scontrato con il seguente errore di configurazione: “Could not find the dialect in configuration”. Il problema è dovuto ad un cambiamento nei nomi delle proprietà di configurazione di NHibernate, infatti se vogliamo utilizzare Castle ActiveRecord nell’ultima build compatibile con NHibernate 2.0 dobbiamo togliere dal nome delle proprietà di configurazione il prefisso hibernate, come mostrato qui sotto:

/ Read Article /