UserControl in Placeholder buono / cattivo? + Problema postback

3

Attualmente sto lavorando un po 'con ASP.NET e sto cercando di trovare il modo migliore per navigare tra le pagine. Al momento ho un UpdatePanel che ha un Placeholder al suo interno. Questo Placeholder aggiungerà quindi il usercontrol di cui ho bisogno.

Mi sono guardato intorno su Internet e alcuni dicono che questa è una cosa veramente brutta da fare, mentre altri la usano senza problemi. È tutto UserControl all'interno di Placeholder all'interno di updatepanel buono / cattivo?

Mentre cercavo di implementarlo, ho riscontrato un problema con postback . Quando faccio clic su un pulsante nella mia "Pagina principale" per aggiungere un nuovo UserControl a Placeholder , la pagina. IsPostback è ovviamente lo stesso su UserControl e quindi sarà sempre vero qui.

Sto facendo qualcosa di sbagliato o devo usare una variabile di sessione per mantenere il mio UserControlPostback forse?

Sono aperto a tutte le opzioni, ho solo bisogno di trovare il modo preferito.

    
posta Thomas 13.01.2012 - 09:58
fonte

1 risposta

1

Penso che sia necessario fare un passo indietro e dire "Are UpdatePanels spawn of Satan?".

Ma seriamente, il modo in cui stai tracciando ha alcuni effetti collaterali piuttosto negativi (anche se è una possibile strategia per lavorare con contenuti dinamici nei WebForm di ASP.net e io stesso ho adottato un approccio simile).

Il primo effetto collaterale che otterrai è che i contenuti aggiunti dinamicamente non persistono dopo un postback, quindi dovrai aggiungere nuovamente il tuo UserControl al segnaposto in Page_Init se desideri gestire i dati di tutti i moduli pubblicati. Questo può causare problemi se non hai modo di dire quale UserControl hai aggiunto al segnaposto, ma ho già implementato una tale soluzione senza che questo sia un problema eccessivo.

Il secondo effetto collaterale è l'enorme quantità di ViewState che raccoglierai mentre i tuoi UpdatePanel si occupano della loro attività. ViewState è abbastanza malvagio, e quando lo si invia da e verso il server con ogni richiesta, combinato con esso è molto grande, può fornire alcuni gravi problemi di velocità dal punto di vista dell'utente. Ti suggerirei se vuoi seguire questa strada dovresti provare a disabilitare ViewState per qualsiasi controllo che non ti aspetti di recuperare i dati da una data successiva.

L'altro problema che mi viene in mente è la replica dello stato della pagina. Quando si riceve un rapporto sui difetti da un tester (o utente), con l'approccio dinamico UpdatePanel, è necessario registrare una serie di passaggi per replicare lo stato del sistema. Se ti avvicini da una prospettiva di caricamento della pagina guidata dall'URL, in cui ogni URL (con dati della stringa di query) rappresenta uno stato della pagina, la quantità di tempo che dovrai prendere per rintracciare un problema sarà (si spera) ridotta all'importo di tempo che ti porta a copiare un URL e incollarlo nella barra di navigazione del tuo browser. Personalmente ritengo che questo sia l'argomento più convincente per cercare di evitare un approccio allo stato web quando possibile.

A mio parere, sarebbe meglio ottimizzare i tempi di caricamento della pagina per evitare il problema di fare postback completi richiedendo troppo tempo, quindi di utilizzare le funzionalità AJAX e il template JavaScript per gestire le richieste lato client. Certo, è molto più vicino al metallo, quindi dovrai scrivere più codice, ma le astrazioni come UpdatePanel spesso hanno solo pochi casi d'uso in cui sono utili, con il caso d'uso particolare di UpdatePanel "Prendi la porta velocemente , non farlo in fretta ".

    
risposta data 07.03.2012 - 18:53
fonte

Leggi altre domande sui tag