Entity Framework ed NHibernate a confronto

Querying del database e fetch dei dati

Il valore aggiunto fornito da un O/RM si esprime maggiormente nella fase in cui si torna su database a recuperare i dati salvati in precedenza. Sia NHibernate che ADO.NET Entity Framework, infatti, consentono allo sviluppatore un'enorme flessibilità tanto nella composizione dinamica delle query quanto nella selezione delle strategie di fetch (eseguire più select in cascata o è preferibile una join?) più opportune; entrambi esponengo due modelli di querying, uno ad oggetti e uno basato su stringhe simil-Sql:

• LINQ to Entities e EntitySQL per ADO.NET Entity Framework
• QueryByCriteria e HQL nel caso di NHibernate.

La principale differenza tra i due prodotti è sostanzialmente rappresentata dal fatto che Entity Framework supporta nativamente la tecnologia LINQ, grazie alla quale è possibile scrivere codice molto leggibile, intuitivo e soprattutto fortemente tipizzato:

var customersFromMilan = 
    from c in context.Customers 
    where c.Sede.Citta.Provincia = "MI" || 
          c.Sede.Citta.Provincia = "RM" 
    select c;

LINQ invece manca in maniera pressoché totale in NHibernate: esistono diversi tentativi non ufficiali di colmare questa lacuna nel mondo open-source, ma allo stato attuale sono tutti ancora in fase sperimentale e pertanto la loro adozione in software di produzione è sconsigliata. L'uso di QueryByCriteria rimane allora l'unica valida alternativa nel caso si necessiti di un query model a oggetti, ma il risultato è decisamente prolisso e meno leggibile di quanto si sia riusciti a scrivere nello snippet di codice precedente:

ICriteria criteria = 
  session.CreateCriteria(typeof (Customer)) 
    .CreateAlias("Sede", "s") 
    .CreateAlias("s.Citta", "c") 
    .Add(Expression.Or( 
        Restrictions.Eq("Sede.Citta.Provincia", "MI"), 
        Restrictions.Eq("Sede.Citta.Provincia", "RM")));

Purtroppo i risultati ottenuti analizzando le query prodotte lato database non sono altrettanto favorevoli ad ADO.NET Entity Framework e ne rappresentano il vero e proprio tallone d'Achille. All'aumentare della complessità delle query o del modello di dominio (basta utilizzare l'ereditarietà per rendersene conto), l'engine produce SELECT lunghe anche diverse decine di righe, che risultano di fatto inutilizzabili in uno scenario in cui si voglia garantire una certa scalabilità al sistema. Esistono dei workaround per limare il problema, come quello basato sulle stored procedure proposto in quest'articolo, ma sicuramente si tratta di un problema che ci si aspetta quantomeno mitigato nella prossima versione.

Come nota conclusiva di questo paragrafo, è doveroso citare una feature estremamente interessante di NHibernate, vale a dire l'integrazione dell'engine di persistenza con la cache di secondo livello. Grazie ad esso è possibile specificare in maniera del tutto dichiarativa la volontà di memorizzare in cache una certa entity per far sì che essa venga sia sfruttata in fase di recupero dati, sia automaticamente invalidata nel caso una Save abbia provocato delle modifiche; il più delle volte è sufficiente aggiungere ai file di mapping la dicitura

<class name="Entity" table="Entities"> 
  <cache usage="read-write"/> 
 
  ... 
</class>

perchè tutto funzioni e, salvo casi particolari, è possibile integrare la cache in un'applicazione già realizzata modificando in maniera estremamente marginale (o addirittura per nulla) il codice esistente.

Conclusioni

La prima versione di ADO.NET Entity Framework rappresenta il primo approccio di Microsoft al mondo degli O/RM; tra gli obiettivi ha quello di rivolgersi al grande pubblico (magari anche a professionisti che fino ad oggi hanno sempre utilizzato i DataSet) e quindi ha l'obbligo di non stravolgere completamente il modello comportamentale del vecchio ADO.NET. Come tale, pertanto, soffre ancora di qualche "peccato", più o meno voluto, di gioventù, ma sicuramente si tratta del prodotto univocamente ritenuto più futuribile, che avrà già nella prossima versione 4.0 una gran ventata di novità, frutto anche del feedback continuo che gli utenti stessi hanno potuto fornire al team di sviluppo sul loro blog. Da un certo punto di vista, quindi, potrebbe essere interessante acquisire oggi delle skill in previsione di questa nuova release.

Da un punto di vista meramente tecnico, invece, non c'è dubbio che attualmente NHibernate sia superiore: è un prodotto più completo e versatile, con una community molto attiva, ben documentato e manutenuto (queste ultime due caratteristiche non sono affatto scontate in un prodotto open source).

Quale scegliere? Sicuramente se è necessario interfacciarsi con un database legacy o non si ha la possibilità di ridisegnare da zero il dominio dell'applicazione, NHibernate costituisce una scelta pressoché obbligata. Per tutti gli altri scenari non esiste invece un'alternativa giusta e una sbagliata: in questo articolo si è cercato di mettere in luce alcune peculiarità e limiti di entrambi i prodotti, così che si possa avere un'idea il più possibile completa e obiettiva in fase progettuale circa la tecnologia da adottare.

Sullo stesso argomento

Commenti

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Segnala su: