Il titolo è un po ' provocatorio, ma non potevo usare i termini che sono usciti dalla mia bocca ieri dopo che ho aggiornato la mia web application alla nuova versione di ATLAS, ossia Microsoft Ajax Framework Beta 1.
Premetto che di Atlas ho usato esclusivamente UpdatePanel e ProgressControl in quanto solo questi permettono ad un sito web di fare un salto di qualità notevole, in termini di usabilità ed anche performance(partial rendering = meno dati inviati)
CASO "UPDATE PANEL"
Nel mio caso specifico ho un repeater che visualizza categorie di un catalogo.Sul click della categoria avviene un postback da cui recupero l'id della categoria cliccata e rifaccio il databind del repeater caricando quindi le categorie figlie di quella cliccata.
L'update panel mi serve unicamente per poter gestire il partial rendering sulla navigazione delle categorie.
Quindi nessun codice da implementare, ma solamente il tag dell'UpdatePanel che "wrappa" il mio repeater.
Dopo aver installato la Beta 1, non funziona più la navigazione del catalogo.
Mettendomi a debug ho potuto constatare che sul primo click entro nell'evento ed ho correttamente il valore dell' id(per esempio CommandArgument = 3) e mi viene generato correttamente il livello figlio.
Sul secondo click fatto sul nuovo livello caricato, entro sempre nell'evento, ma il valore che mi viene passato nel CommandArgument è relativo al valore dell'elemento nella stessa posizione ma del livello padre(quindi mi arriva ancora 3).
Il postback sembra quindi funzionare ma in modo non corretto, in pratica sembra che generi l'evento utilizzando i valori memorizzati nel viewstate al primo databind del repeater non considerando che un postback "parziale" è stato invece fatto.
Non sono riuscito a trovare soluzioni!
CASO UPDATEPROGRESS
L'update progress messo in un template di un controllo custom che ho realizzato non viene più renderizzato:
....
Con la CTP funzionava, con la Beta 1 no.
Potrebbe essere un problema del mio controllo custom ? E' da verificare comunque il perchè con la CTP tutto era perfettamente funzionante.
VARIE ED EVENTUALI
Non mi piace il fatto che il "core" assembly di Ajax vada nella GAC e che per forza lo debba referenziare mantenendolo nella GAC.
Spesso e volentieri è pratico e comodo poter copiare semplicemente gli assembly nella bin dell'applicativo web.
CONCLUSIONE
Penso che per ora ritornerò alla CTP.
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 ? 