Ciao Mauro,
[quote user="Mauro Servienti [MVP]"]Ciao petrux, Quale � il problema? Io non � che adori il repository pattern se non in scenari dai contorni molto ben delineati. [/quote]
Il problema è che non a capisco a cosa possa servirmi. Quindi se mi fai un qualche esempio sui questi scenari ne sarei ben contento. :-)
Grazie,
petrux
--
Principalmente fa comodo per il testing, soprattutto se lavori con repository in cui hai metodi del tipo
IOrderRepository.GetGoldOrders
dove i gold orders sono presi con criteri molto complessi. In questo scenario puoi sostituire il repository con un mock quando serve e facilitarti il test.
alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
'giorno Petrux, prova a dare una occhiata agli ultimi changeset di NSK, perchè credo che troverai risposta ad alcune delle tue domande :-)
Ciao Andrea,
Andrea Saltarello: 'giorno Petrux, prova a dare una occhiata agli ultimi changeset di NSK, perchè credo che troverai risposta ad alcune delle tue domande :-)
Ok, cercherò di farlo ASAP.
Intanto grazie e alla prox,
Sostanzialmente spesso adotto un approccio di questo tipo. Usando Nhibernate il repository si appoggia semplicemente a nhibernate per la persistenza, ma in generale se non hai nhibernate è il repository che dialoga con il DAL.con Castle.nhibernate facility inietto il sessionManager nel repository, cosi il repository quando deve accedere al DAL prende la session corrente e fa quello che deve fare.
Per le transazioni dipende dall'ambiente, in asp.net si gestisce il tutto con un httpmodule. Alla prima creazione della sessione il sessionmanager crea la sessione ed inizia una transazione, e nell'end request ed error si committa o si rollbacka. In alcuni progetti ho dei gestori di sessione sulla falsariga di quelli di castle, in sostanza si occupano di capire quando la sessione deve essere chiusa (e cosi alla successiva richiesta ne viene generata una nuova) e quando fare le transazioni.
Tutti i repository sono solitamente singleton, dato che quello che cambia nel loro "contesto" è il sessionfactory che semplicemente restituisce la sessione attualmente nel "contesto". Chiaramente non è tutto facile, :) ma in generale questo approccio mi semplifica la vita perchè a quel punto l'unico dato realmente importante è la sessione che viene gestita da un gestore centralizzato e quindi i repository sono piuttosto semplici.
Ad esempio in MVVM e WPF potresti fare in modo che la sessione shari la sua vita con il ViewModel.
Alk.
Ogni volta che usi un ORM, il ciclo di vita della Sessione è fondamentale. In un MVVM puoi fare si che ogni View Model abbia la sua sessione, e che venga distrutta solamente quando il ViewModel venga disposato. In questo modo ad esempio gli oggetti caricati possono avvantaggiarsi del lazy load durante il binding (anche se questa non è l'opzione che preferisco)
Ciao Alk,
Gian Maria Ricci: Ogni volta che usi un ORM, il ciclo di vita della Sessione è fondamentale. In un MVVM puoi fare si che ogni View Model abbia la sua sessione, e che venga distrutta solamente quando il ViewModel venga disposato. In questo modo ad esempio gli oggetti caricati possono avvantaggiarsi del lazy load durante il binding (anche se questa non è l'opzione che preferisco)
A occhio ti direi che ho capito. Aspetto lunedì per un esempio hands-on. :-)
Ciao,
Giulio
In questo periodo sono veramente "incasinato" per molti motivi :( per cui non riesco a preparare un esempietto, ma prometto che appena ho tempo lo faccio perchè stamattina un altro collega mi ha fatto una domanda simile :) per cui prima o poi mi servirà avere un po di codice stupido da fare vedere.