L'ingresso di Microsoft nel Web 2.0 si chiama per i più UpdatePanel: "ASP.NET UpdatePanel controls enable you to build rich, client-centric Web applications. By using UpdatePanel controls, you can refresh selected parts of the page instead of refreshing the whole page with a postback. This is referred to as performing a partial-page update. A Web page that contains a ScriptManager control and one or more UpdatePanel controls can automatically participate in partial-page updates, without custom client script." (UpdatePanel Control Overview).
Ma oltre all'aspetto funzionale quanti conoscono davvero come funziona un UpdatePanel? Vi state chiedendo se è davvero necessario saperlo? IMHO si, in modo da operare la scelta tecnologca più corretta; sono infatti convinto che le scelte non sono assolute ma sempre determinate dal contesto di applicazione.
Credo si possa riassumere il funzionamento di un UpdatePanel dicendo quanto segue: permette di intercettare eventi client side (trigger) che trasferisce al server in backgroud (async postback); il server riceve lo stato della pagina, intercetta l'evento server side che ha causato il postback e ritorna i dati relativi all'aggiornamento della sola porzione di pagina gestita dall'UpdatePanel. Il controllo promette quindi di ridurre traffico di rete e garantisce meno effetto flickering sulla pagina.
Nonostante gli evidenti benefici lato utente questi sono i risultati applicati ad una pagina con una gliglia paginata: in approccio classico (reload completo ad ogni cambio pagina) 2264 bytes in richiesta e 8034 bytes come response; in un approccio con UpdatePanel 2378 bytes in richiesta e 7114 bytes come response; ovviamente la misura dipende dalla pagina a cui si applica il test (in "AJAX Application Architecture, Part 1" i risultati sono infatti differenti).
Quello che voglio fare ora è analizzare l'approccio UpdatePanel vs uso diretto della api di Ajax. Nel confronto prendo come riferimento funzionalità molto semplici che potremmo voler inserire in ogni pagina per monitorare ad esempio lo stato di elaborazioni, richieste o alerting. Nel mio caso ho scelto di inserire un orologio aggiornato in tempo reale - ad intervalli di 1 secondo - con l'orologio del server, esempio stupido ma rapido da implementare ai fini di un benchmark.
Cosa intendo per uso diretto delle api di ajax? Intendo l'implementazione di funzioni javascript che mediamo XMLHttpRequest richiamano una pagina ad hoc e usano la response per aggiornare/ridisegnare il contenuto di uno specifico div. Il traffico di rete si riduce notevolmente; nell'immagine sottostante in giallo approccio ajax diretto, in rosso approcio ajax con UpdatePanel.
In realtà lo scopo di questo mio post non è mostrare quanto un uso custom delle funzioni ajax possa ridurre il traffico ma voglio mettere in evidenza quanto l'uso di ajax mediante UpdatePanel solleciti il server. Sebbene infatti il controllo permette la gestione di aggiornamenti parziali di pagine (e il client ne trae giovamento) la pagina server-side deve essere ogni volta ricostruita interamente. Credo si possa dire che l'UpdatePanel lavora a livello di rendering del postback. Nell'esempio ho usato una pagina con uno usercontrol di testata. Tracciando gli eventi si vede che l'UpdatePanel mette in gioco ogni componente anche se poi la regione della pagina effettivamente aggiornata è molto piccola. Se i metodi di Page_Load sono male implementati, l'uso di UpdatePanel potrebbe diventare altamente inefficiente server-side.
Qual'è la mia preferenza? Personalmente non mi piace come è stato implementato l'UpdatePanel... anche se è sicuramente il modo migliore per venire in contro a sviluppatori a cui non interessessano - per validissime ragioni - le problematiche qui descritte ma sono più orientati allo sviluppo rapido di soluzioni web 2.0 . Uso gli UpdatePanel? Per scenari complessi (esempio la paginazione di una griglia o aggioramento di porzioni di pagina che dipendono dallo stato della pagina stessa) ovviamente si, in quanto non vedo disponibili altri componenti per soluzioni alternative che siano anche accettabili in termine di produttività.
Per scrivere questo post sono stato supportato da Web Development Helper e dall'immancaibile TcpTrace.
oO0( Siete curiosi di vedere il codice? Contattatemi! )
posted @ domenica 29 giugno 2008 13:39