Da più di un anno ho sviluppato e mantengo una mia soluzione Domain-centrica per cercare di sviluppare applicazioni web secondo un approccio appunto orientato al dominio.
Revisioni successive mi hanno portato quest'estate ad evolvere tale progetto verso le novità di C# 2.0 approffittando di caratteristiche quali generics e partial classes.
Come già avevo scritto sul mio blogs, sono un "affezionato" sostenitore della generazione automatica del codice e mi sono servito di CodeSmith per crearmi templates che mi possano generare automaticamente tutto il mio strato DAL, IDAL, BLL e di Entities.
Qualcuno potrebbe storcere il naso dal momento che diversamente dai puristi del Domain Driven Design genero le classi dal database e non faccio, come teoria vorrebbe, il contrario.
Probabilmente bisogna distinguere in base al tipo di applicativi che si stanno sviluppando.Intendo dire che quando si progetta una applicazione di cui si conosce già abbastanza bene il dominio è più semplice poter cominciare la progettazione direttamente dal database.
Diversamente per applicativi nuovi e di cui non si ha conoscenza e analisi approfondita, puo' invece tornare utile seguire l'approccio per cui prima disegno il mio modello di dominio e poi lo traduco verso quello che sarà il mio sistema di persistenza(il database generalmente).
In quest'ultimo caso è più facile collaborare per la stesura del modello anche con personale non tecnico, mentre quando si parte dal database ovviamente le competenze devono essere altre.
Dopo aver partecipato al workshop di settimana scorsa, mi sono deciso a scaricare NSK per poterne visionare i sorgenti e prenderne spunto per migliorare quanto costruito da me.
NSK implementa, diversamente da me, la Unit Of Work.
L'utilizzo di UoW è sicuramente utile in scenari in cui è necessario garantire che più operazioni vengano eseguite in transazione.Scenari in cui si vuole che la persistenza sia da applicarsi solo alla fine di operazioni che coinvolgono più Entitities(se pensiamo per esempio ad una form dotata di tabs in cui la conferma dei dati prevede il salvataggio di tutti i dati dei vari tabs).
Dal mio punto di vista non so quanto la UoW sia utile in scenari "stateless" come quello web.Certamente non dico che non si possa utilizzare, ma probabilmente è una forzatura che richiede di doversi preoccupare di mantenere lo stato delle UoW anche tra diverse richieste(o postbacks).
Altra cosa interessante di NSK mi è sembrato inizialmente il fatto di utilizzare i generics per gestire le interfaccie dei vari providers e i metodi CRUD della UoW.
Quindi in questo caso non ho bisogno di avere una IProductDataProvider, dal momento che ProductDataProvider concreta derivarà da IDataProvider.
Ma è quei che nasce la mia perplessità più grossa.Come faccio con una architettura del genere ad implementare dei metodi di persistenza custom?
Mi spiego meglio.Oltre ai metodi CRUD ho bisogno spesso di avere dei metodi custom che si appoggino a query fatte ad hoc.
Con il sistema che uso io(e che se non ricordo male rispecchia per quando riguarda queste caratteristiche la prima implementazione di NSK, forse quella originale) ho l'interfaccia IProductDataProvider che oltre a contenere i metodi CRUD può essere usata per aggiungere i metodi custom di cui sopra.
Nel caso di NSK non riesco a capire come possa fare questo. Dalle classi "service" ho la referenza alla IUnitOfWork che pero' è generica per tutti i providers.
Forse mi è sfuggito qualcosa e forse ci ho guardato troppo velocemente...e non vedo la soluzione che è dietro l'angolo ? 