E' innegabile che, nell'ultimo anno, si faccia un gran parlare in rete di O/RM ed in particolare di NHibernate. Capita sempre più spesso di leggere un post qui, un articolo lì e soprattuto tante, tantissime domande su forum e newsgroup di persone in qualche modo affascinate o incuriosite da questo modo relativamente nuovo di gestire le problematiche di persistenza.
Ciò che mi ha sempre colpito è come, a ragion veduta, in molti vedano in NHibernate un qualcosa che finalmente si occupa di scrivere SQL al posto nostro. Ma in realtà c'è molto, molto di più in quel dannato assembly, features che tante volte passano quasi inosservate, che raramente sono citate in articoli, ma che invece rappresentano tutte, secondo me, piccole rivoluzioni nel modo in cui scrivere il nostro data access layer.
Un esempio tipico è quello della cache di secondo livello. Ho recentemente sviluppato un piccolo CMS e l'ho fatto tralasciando (volutamente) l'argomento caching, leggendo ogni volta che ne avevo bisogno i dati sul database. L'ho fatto perché ho preferito focalizzare la mia attenzione su altri aspetti, perché la cache a mio modo di vedere deve essere uno strato intermedio tra il DAL e il layer superiore, e soprattutto perché secondo me deve essere il più possibile trasparente ad entrambi.
Bene, ad applicazione completata e funzionante, già installata in un server per fini dimostrativi, quanto costa implementare un sistema di caching? Con NHibernate è bastato inserire un paio di righe su file di configurazione e un elemento <cache> nel mapping di ogni entità.
Risultato: il CMS ha iniziato a memorizzare nella cache di ASP.NET (ma supporta anche cache distribuita in scenari webfarm) ogni entità recuperata dal DB, preoccupandosi automaticamente di invalidarla ad ogni nuova scrittura. Ho potuto controllare quanto tempo al massimo una entry può restare in cache, quante entità di dominio voglio memorizzare e quali possono essere considerate invariabili.
Il tutto *SENZA SCRIVERE UNA RIGA DI CODICE*.
Fate voi.
Technorati tags:
NHibernate