Si anche io - nonostante non amante degli ORM - ho iniziato a giocare con NHibernate. Avevo già avuto esperienze con iBatis ma la tecnologia mi sembrava ancora troppo acerba... ho cominciato a interessarmi nuovamente dopo l'ultimo workshop e la sessione di janky. Avevo poi chiesto lumi su alcuni dettagli e in effetti mi sono convinto che valeva la pena provare a pendere del tempo. ..."bando alle ciance" e veniamo al dunuque. Prima di iniziare diamo i dettagli tecnici della versione di NHibernate: 1.0.3.0.
Vi ricordate quando vi raccontavo "ADO.NET, i parameter e l'importanza dei tipi precisi"? Ecco oggi facendo delle prove mi son chiesto... ma NHibernate come si pone di fronte al problema dei parametri?! Come sospettavo tutte le stringhe vengono rimappare come parametri NVARCHAR(4000).
Per cui facciamo finta di avere un campo CHAR(5) - il classico codice parlante - che noi mappiamo verosimilmente con:
<ID column="CODICE" name="Codice"><GENERATOR class=assigned /></ID>
Bene poichè non specifichiamo il "type" NHibernate deciderà di farlo trattare a ADO.NET che di default mappa le stringhe come NVARCHAR(4000) - la cosa la si può vedere profilando i comandi -... e questo a fini delle performance è molto molto male! Ho controllato per vedere se era stato definito un type adeguato... credo di averlo identificato in "NHibernate.Type.AnsiCharType" che come dice il commento "Maps a System.Char Property to a DbType.AnsiStringFixedLength column". Purtoppo un intricato sistema di costruttori - a mio avviso un pò mal disegnati/strutturati - mi hanno impedito di usarlo in alcun modo :(
Sul "lady-bug di NHIbernate" ho trovato questa segnalazione "Register of AnsiChar type"... lo issue NON è recente (Jan-06) ed è marcato come risolto. Chiederò maggiori informazioni per capire come risolvere il problema.
Tuttavia una nota di demerito va detta sulla mancanza di sensibilizzazione al problema... e i manuali - per lo meno la reference che ho scaricato - non sono sensibili all'importanza di usare - ad esempio - DbType.String invece di usare DbType.AnsiString quando si definisce un parametro del nostro command. Insomma invece di insegnare a sfruttare le performance usando il lazy load o il caching bisognerebbe spiegare in primis a mappare quanto più correttamemte i dati non solo indicando le cose ovvie ma anche quei dettagli troppo spesso trascurati.
- oO( Di tutte queste cose mi confronterò meglio con il janky! :-p ) -
posted @ venerdì 19 gennaio 2007 00:06