Quando si adotta un O/RM per realizzare lo strato di accesso ai dati dell'applicazione, si sceglie sostanzialmente di utilizzare un framework di terze parti a cui delegare per intero la logica di interazione con la base dati. Per questo motivo è assolutamente necessaria un'attenta valutazione sulle peculiarità (e sulle lacune) dei diversi prodotti sul mercato, anche perchè, per quanto si possa progettare bene l'architettura, solitamente non è cosa semplice tornare indietro sui propri passi. Attualmente, sebbene le possibilità di scelta siano molto numerose, l'attenzione del grande pubblico è focalizzata su due specifici framework nati con lo stesso scopo, ma provenienti da mondi quasi agli antipodi: NHibernate e ADO.NET Entity Framework.

NHibernate e ADO.NET Entity Framework: le origini

NHibernate è un prodotto open source, nato circa 4 anni fa come porting dell'Hibernate di Java, portato avanti da un gruppetto di appassionati fino a diventare, nel corso degli anni, più o meno il punto di riferimento nel suo ambito. Si tratta di un progetto considerato oramai maturo, che ha visto susseguirsi un gran numero di rilasci (l'ultima versione pubblicata è la 2.1) e dichiarato stabile da diversi anni. Sull'accoppiata Hibernate/NHibernate, infatti, sono basate numerosissime applicazioni di livello enterprise, tra cui spiccano nomi celebri quali Ebay, AT&T o Cisco, come ben documentato sia sull'attuale sito ufficiale, sia da JBoss per quanto riguarda l'originale per Java.

ADO.NET Entity Framework, invece, ha una natura completamente diversa essendo stato rilasciato da Microsoft a partire dal SP1 del .NET Framework 3.5. Sebbene gratuito, infatti, si tratta a tutti gli effetti di un prodotto commerciale, da molti ritenuto come quello più futuribile tra gli O/RM disponibili in .NET, che però ad oggi non può onestamente vantare il pedigree del suo concorrente.

Una prima valutazione, quindi, deve basarsi sulla vera e propria natura del framework da scegliere: optare per un prodotto Open Source pone effettivamente dei rischi, dato che si tratta pur sempre di un qualcosa manutenuto da un piccolo team di appassionati, dato che non c'è garanzia che un bug venga corretto e non è garantita la completezza della documentazione (sebbene la community attorno ad NHibernate si prodighi parecchio per assolvere anche questi compiti). D'altro canto, però, i rilasci di nuove versioni sono estremamente più frequenti di quanto accade ad un prodotto commerciale come ADO.NET Entity Framework, per il quale invece è lecito aspettarsi aggiornamenti solo con nuove versioni del .NET Framework o in concomitanza con le pubblicazioni dei service pack. Un altro aspetto da tenere in considerazione è quello relativo alla diffusione, e in questo caso il fatto che l'ORM targato Microsoft sia più giovane di NHibernate si traduce in una maggiore difficoltà nel reperire articoli o post esplicativi in Internet. Anche questo è però un campo in cui ci si aspetta un balzo in avanti di Entity Framework in un lasso di tempo relativamente breve.

Il mapping: come colmiamo il gap tra entity e modello relazionale

Una delle caratteristiche di maggior pregio di ADO.NET Entity Framework è l'integrazione con Visual Studio che, tramite il designer dell'Entity Data Model, consente intanto di importare uno schema di database con pochissimi colpi di mouse, costruendo automaticamente il relativo modello a oggetti e, in seguito, di apportare eventuali modifiche rappresentando graficamente concetti architetturali come associazioni o relazioni di ereditarietà.

Il vantaggio di questo approccio è sicuramente quello di un'enorme produttività, visto che, mano a mano che l'utente opera sul diagramma, un generatore di codice si occupa di creare e aggiornare definizione delle classi e relativo mapping, rendendo quindi effettivamente molto semplice e veloce questo task.

Purtroppo, però, anche in questo caso ADO.NET Entity Framework mostra qualche piccolo peccato di gioventù; non è infatti possibile utilizzare da designer tutte le funzionalità disponibili (un esempio su tutti è rappresentato dai complex type) e in alcuni casi è pertanto richiesto di "sporcarsi" le mani agendo direttamente sul XML, operazione che sulle prime risulta poco intuitiva e che richiede quindi qualche skill in più. In secondo luogo – e questa forse è la lacuna più grave – l'O/RM targato Microsoft è piuttosto rigido nella definizione del modello a oggetti e, ad oggi, non è pensabile l'utilizzo di un dominio che si discosti più di tanto da quanto presente sulla base dati; in altre parole, insomma, in presenza di database legacy, adottare ADO.NET Entity Framework può condurre su una strada irta di difficoltà.

NHibernate, d'altro canto, non presenta ad oggi un designer grafico, sebbene ci siano diversi tentativi "amatoriali" di crearne di più o meno efficaci: il mapping deve essere descritto in uno o più file XML o, eventualmente, realizzato tramite l'utilizzo di custom attributes sulle entity (anche se questa è a tutti gli effetti una pratica poco elegante oltre che scomoda e scarsamente supportata). L'assoluto punto di forza, in quest'ambito, è però rappresentato dalla grandissima versatilità che questo framework offre riuscendo a gestire ugualmente bene sia schemi relazionali normalizzati e progettati con tutti i crismi, sia basi di dati prive di foreign key, in cui magari le relazioni tra le tabelle siano espresse utilizzando addirittura campi non chiave, o in cui si faccia uso di chiavi composite (concetto che, storicamente, ha dato filo da torcere a parecchi software di questo tipo). La scrittura delXML richiede però una certa pratica e una buona dose di studio e, nonostante il supporto dell'intellisense di Visual Studio dia un'ottima mano, il gradino di apprendimento necessario è sicuramente più elevato di quello di Entity Framework.

Dal punto di vista della struttura delle classi del domain model, NHibernate pone molti meno vincoli rispetto ad Entity Framework, consentendo quindi la realizzazione di domini agnostici allo strato di persistenza. Ovviamente, come già detto, non essendo presente alcun generatore integrato in Visual Studio (se non il vecchio Class Designer), resta allo sviluppatore l'onere di scrivere il codice di ognuna delle entità.