Lunedì ed ieri ho frequentato il corso di ObjectWay tenuti da Janky su NHibernate.
Due giornate veramente tirate dal punto di vista dell'impegno, ma vi posso garantire che se ci fosse stato un terzo giorno ci sarei andato con ancora più entusiasmo del primo...
Vorrei condivedere alcune (4) considerazioni che potrei definire gli slogan di quanto appreso, filtrato attraverso la mia esperienza di professionista informatico che ha sempre lavortato in ambito di piccole imprese sw (bè diciamo anche micro...)
In prima battuta 2 considerazioni molto dev
1) ORM (quindi NHibernate) viene DOPO Domain Driven Design (DDD), ne è una naturale ed imprescindibile conseguenza. In altre parole ha senso usare un ORM se il vostro stile di programmazione è orientato al modello di dominio, ossia PRIMA di approdare ad un ORM è necessario aver bene in mente che cosa significhi DDD. Questa per me è stata la piacevole conferma di un'idea che mi ero fatto in questi mesi. Usare un ORM così pensando che sia solo un altro modo di avere un DAL è un errore grossolano, di quelli che prima o poi si pagano molto molto cari.
2) SQL, SQL, SQL, SQL, SQL, SQL e anche SQL!!!!!!!!!! NON pensate MAI che usare NHibernate (o un qualsiasi altro ORM) significhi "finalmente mi scordo del DB". Questo è, confessiamolo, un sacro Graal di noi tutti "veri" dev che in fin dei conti detestiamo il db e il mondo dei dba... bè quello che vi dico è: questo è un ERRORE grossolano. Ho fatto più SQL in questi due giorni che in tutto l'anno scorso (ovviamente esagero, ma ci siamo capiti). NHiberante, per quanto riguarda la sua configurazione statica (ma anche nel suo compoirtamento dinamico) ha una serie enorme di settings che incidono pesantemente sul modo in cui viene interrogato il DB. Fare tuning su NHibernate significa SQL Profiler, significa SQL e poi ancora SQL e un pizzico di SQL (e perchè no anche dell'SQL). Quindi scordatevi di prescindere dal DB (fra l'altro ho scoperto che alla fine NHibernate una volta terminato il tuning è come se lavorasse tramite stored procedure anche se non esitono stored procedure propriamente dette, sarebbe troppo lungo da spiegare in dettaglio... ecco l'ho detto... ora Janky mi uccide)
E ora 2 considerazioni di profilo "aziendale"
3) Non è pensabile, almeno in una realtà di produzione sw piccola, fare tuning su grosse banche dati modificando a mano ogni singola eventuale stored procedure al fine di ottimizzarne l'SQL. Credo che mediamente ogni persona che scrive SQL non riesca alla prima, soprattutto per query complesse, a produrre un'interrogazione efficiente ed ottimizzata. lo stesso discorso accade per NHibernate, e cioè, il mapping sul DB deve essere necessariamente ottimizzato per raggiungere i livelli di quality of service e requisiti non funzionali prefissati (ricordo che il mapping determina il modo in cui NHibernate scatena le query sul DB). in entrambi i casi è necessario fare del tuning facendo test di carico e verificando la risposta del DB, però esiste una enorme differenza nel modo in cui riesco a condurre tali test in caso di SQL da modificare a manina nelle stored procedure, e SQL da modificare andando a lavorare sui settings di n file di mapping, semplicemente non c'è confronto in termini di tempo e di creazione di ambienti semi-automatici di scenari.
4) Per frequentare il corso aziendalmente mi è costato come per 4 giornate lavorative (le 2 in cui non ho lavorato e le circa 2 del costo del corso). Il saldo del dare avere è però in pauroso attivo: per apprendere quello che ho appreso, anche a seguito del fitto domanda-risposta su casi reali a cui abbiamo sottoposto Janky, non credo sarebbero bastati 6 mesi... fate voi.
Un grazie enorme a Janky che davvero è stato un docente spettacolare ed è andato al di là del semplice corso foraggiandoci a piene mani della sua esperienza davvero preziosa che ha accumulato su NHibernate.
Però Janky... CI AVEVI PROMESSO LE MODELLE E NON NE ABBIAMO VISTA NEMMENO UNA!!!!!!!!!!!!!!!!
saluti