Il titolo del post farebbe pensare ad una versione estiva del menù del giorno e invece l'argomento non fa pensare a tavole imbandite.
In realtà, anzi, l'argomento è tutt'altro che leggero... Non so neanche come descriverlo quindi faccio qualche passo indietro.
Qualche mese fa il buon Janky mi ha iniziato ai veri piaceri del contesto di persistenza. Da lì son partite le prime considerazioni e le prime chiacchierate con chi era, come il sottoscritto, in balia di quel genere di balordone!
Nel giro di poco (è praticamente un percorso obbligato e guidato) ci si ritrova davanti al pattern Open Session in View per hibernate ed alle varie evoluzioni personalizzate.
Grazie all'IPersistenceContext e relativo NhPersistenceContext il BizLayer torna ad essere stateless, come piace a me ed inoltre la soluzione non è più legata all'architettura di NHibernate, lasciando aperta la compatibilità verso eventuali soluzioni future migliori (se ce ne saranno...).
Data Access Layer
Dopo questo "riepilogo" si arriva al presente: con qualche classe "helper", un project template, qualche item template ed alcuni code snippets per VS2005, scrivere un DataAccessLayer basato su NHibernate diventa realmente una questione di qualche minuto ed i tempi di startup e configurazione sono realmente azzerati. Non devo più neanche inserire i vari parametri nel file di configurazione dell'applicazione perchè questi vengono gestiti direttamente via codice da una delle classi helper ottimizzata per la gestione di NHibernate con database SQL Server; rimane in sostanza da specificare solo la ConnectionString.
Model View Presenter
Tutto bellissimo e poi... poi si arriva ai livelli superiori. Per la UI sto provando ormai ad utilizzare un approccio ispirato al ModelViewPresenter un po' per garantirmi la possibilità di sostituire la View, un po' per cercare di scrivere codice ancora più "pulito" (disaccoppiato?) e lineare.
Avere un Presenter però che si adatti a tutte le View non è assolutamente banale.
Io tendenzialmente (grazie al mitico prof. Falletti) di solito cerco prima di affrontare un problema con la mia testa cercando di riconoscere e capire i problemi ed ipotizzando delle soluzioni, poi mi guardo attorno e cerco di capire come gli altri hanno affrontato lo stesso problema.
In questo caso c'è chi ha deciso di scrivere dei presenter che in realtà non sono realmente svincolati dalla tecnologia delle View, ma comunque generalizzando il più possibile. Nel caso di un cambio di View il codice da modificare risulta decisamente inferire e più "raccolto", ma cmq non è il tipo di soluzione che mi conquista particolarmente.
Però far convivere sullo stesso Presenter da un lato una "WebView" col suo Open Session in View, con l'autenticazione basata su Forms, con la gestione delle eccezioni comunque differente e dall'altro lato una "WinView" sembrava veramente difficile.
Invece, grazie a qualche Abstract Factory qua e là, il tutto sembra essersi risolto in modo sorprendentemente agevole.
Gestione dei settings e transazionalità
A quel punto una volta entrato nella tenda dei vapori di codice ho preso i dubbi per le corna ed ho deciso di fermarmi un attimo per scervellarmi anche sugli aspetti relativi alla gestione dei vari settings di un applicazione e del "rapporto" tra transazioni su database e transazioni distribuite, ma se aggiungo altro a questo post mi ritrovo una bella SmettilaException!!! 
Spero di riuscire comunque più avanti a riversare anche quelle considerazioni per potermele poi rileggere (e solitamente riverificare) in seguito.