Ieri Imperugo di ASPItalia ha pubblicato un post a proposito di NHibernate sul suo blog e
ne è seguita una discussione parecchio interessante con nostromo, Daniele e ricky, proseguita con quest'ultimo anche su MSN.
Un passo di tutto questo disquisire era qualcosa del tipo: "ha senso una Unit of Work in una Web Application, in cui il codice lato server è
solitamente stateless?"
Secondo Riccardo "una UoW ha il compito di creare un contesto transazionale a livello di logica applicativa, cosa che nel web per motivi prestazionali è preferibile fare in altri modi" e quindi scegliere se utilizzarla o meno dipende dai casi; ma dopo essermi confrontato anche con Janky e alla luce
della mia esperienza (che comunque non è paragonabile a quella dei miei
interlocutori), io sono convinto del contrario.
L'esempio è quello di una qualsiasi relazione Master-Detail; pensiamo di
avere un ipotetico oggetto di tipo Fattura, recuperato in qualche modo dal DB.
Tale oggetto ha una collection di DettaglioFattura e ogni Dettaglio ha la sua
bella reference alla fattura stessa. In pratica:
Ora, supponiamo di andare a modificare la composizione delle righe, perché
eliminamo un dettaglio. Io, nel mio codice, voglio limitarmi a scrivere qualcosa
di tipo
miaFattura.Details.RemoveAt(3);
provider.Persist(miaFattura);
Se ci pensiamo, non è banale fare in modo che questo codice funzioni, perché
non faccio nessuna chiamata ad un DAL per il mio dettaglio, che è ancora lì in
memoria e punta ancora alla mia fattura. Ma la Unit of Work si accorge che la
composizione del dettaglio è cambiata e genera una query di DELETE sul DB per
quella riga che è stata rimossa.
UPDATE: Ho scritto una cosa errata, interpretando male il pensiero di Riccardo: egli non dice che NON abbia senso una UoW in uno scenario Web, ma che NON HA SENSO SEMPRE. Mi scuso con il diretto interessato per aver travisato la sua idea.
powered by IMHO 1.3