Introduzione a ConfORM

Chi mi segue su Twitter sicuramente saprà che ultimamente mi sono messo a “giocare” un po’ con ConfORM, e, nello specifico, ho deciso di rimpiazzare FluentNHibernate in Dexter, per far strada al Framework prodotto da Fabio Maulo.

Per chi non lo conoscesse, ConfORM è un Framework che facilità incredibilmente tutta la parte di mapping del nostro dominio - quando si utilizza NHibernate per la persistenza - cambiando totalmente l’approccio; ma andiamo per gradi.

Oggigiorno esistono diversi modi di scrivere il mapping per NHibernate, partendo dal classico e mai datato XML, fino ad arrivare a Framework più recenti come FluntNHibernate, Ddl2Hbm, VisualNHibernate, etc.
Purtroppo questi framework hanno lo stesso approccio, obbligandoci a specificare la corrispondenza di ogni singola property di ciascuna classe di dominio verso il database.

Non conosco i vostri gusti relativamente alla scrittura di codice, ma personalmente ritengo molto noiosa e ripetitiva la fase di stesura del mapping, motivo per cui ConfORM la vince su tutti gli altri.

L’approccio di ConfORM.

Come già accennato ConfORM ha preso totalmente un’altra strada; di fatto inizialmente può lasciare l’utente un po’ spiazzato, ma quando si è capito il funzionamento è sicuramente un viaggio di sola andata, in quanto induce ad abbandonare totalmente il mapping “tradizionale”.
Di fatto quello che è necessario fare è “istruire” ConfORM con le nostre “regole” di sviluppo e di nomenclatura e specificare solo le eventuali eccezioni, lasciando a lui il compito di generare e gestire tutta la fase di mapping.

Per capire meglio il vantaggio, il grafico seguente mostra il Dominio di Dexter che in precedenza era mappato con FluentNHibernate in 27 classi differenti ed ora è mappato in poco più di 20 righe di mapping

 

ClassDiagram1

Maggior Produttività e controllo.

Un altro vantaggio sicuramente interessante è l’aumento di produttività: possiamo aggiungere e togliere classi al nostro dominio senza toccare il mapping, a condizione che queste rispettino le regole stabilite precedentemente.
Quest’aspetto è sicuramente molto interessante perché ci permette di modificare il dominio senza preoccuparci di dover aggiornare il mapping, e riduce il rischio di introdurre errori dovuti ai continui cambiamenti.
Un altro aspetto che adoro è la rigidità che si può introdurre nel lavoro in team, in quanto se qualche sviluppatore non rispetta le regole di mapping prestabilite è obbligato ad andare a dichiarare l’eccezione manualmente e quindi il cambiamento è facilmente identificabile; un esempio banale potrebbe essere la nomenclatura delle tabelle: si è stabilito che sul database esse debbano chiamarsi con il nome della classe di dominio ma al plurare e, se un dev vuol chiamare la tabella in maniera differente è obbligato a gestire lo special case a mano e specificarlo nel mapping.

Performance:

L’utilizzo di ConfORM porta anche vantaggi prestazionali alla nostra applicazione in quanto, a differenza di tutti gli altri Framework di mapping, genera direttamente le classi necessarie a NHibernate per il suo utilizzo, saltando così tutta la fase di parsing del file xml contenente il mapping.
Ovviamente quest’aumento di performance è beneficiabile solo in fase di startup ed è sicuramente apprezzabile quando si ha a che fare con domini piuttosto corposi.
Per capire meglio il funzionamento di ConfORM rispetto al classico mapping o ad altri Framework, riporto qui un grafico “rubato” dal blog di Fabio che spiega perfettamente il perché dell’aumento di performances.

 

confORM

Conclusioni:

Ovviamente seguiranno altri post che mostreranno la parte più tecnica di ConfORM, ma per chi non volesse aspettare riporto alcuni link utili:

  • Download di ConfORM – Download.
  • Una serie di post su ConfORM è disponibile qui.

Enjoy your mapping.


Comments