Quando collegare i gestori di eventi asp.net

Question

Diciamo che abbiamo un modulo piuttosto standard con una casella di testo e un pulsante (per semplicità). Vuoi gestire un evento Click e fare alcune cose in base all'input dell'utente.

Mi chiedevo, importa, esattamente quando si esegue il cablaggio di un gestore di eventi per l'evento Click in un code-behind? Se lo fa, dove è il posto migliore per metterlo? Caricamento della pagina? Page init? Ho provato entrambi i posti, ma non ho notato alcuna differenza. O è solo una preferenza personale del programmatore? Ho già cercato Internet un paio di volte, ma non ho trovato nessuna risposta soddisfacente.

So quando viene eseguito il metodo effettivo, ma non sono sicuro della parte di cablaggio .

Answer 1

Come sapete, ci sono diversi gestori Page_xxx di eventi, come Init, Load, Prerender ... Questo eventi esistono nei controlli, e le pagine così come controlli utente (in realtà stanno forma Control, che detiene tutti derivati questi eventi).

Questi eventi sono legati alla ASP.NET Page Life Cycle

Se leggete la pagina a cui punta questo link con attenzione capirete quando gli eventi vengono attivati. Pertanto, se si associa il gestore di eventi in qualsiasi evento del ciclo di vita della pagina che si verifica prima che gli eventi vengano attivati, è garantito che i gestori di eventi saranno rilegati in tempo per essere attivati.

Queste sono le fasi principali del ciclo di vita:

PreInit -> Init -> InitComplete -> PreLoad -> Load -> [Control events] -> 
LoadComplete -> PreRender -> SaveStateComplete -> Render -> Unload 

eventi Non tutti hanno associato, ma, se è necessario, è possibile ignorare la funzione corrispondente OnXxx(), come OnPreInit(). (Questo di solito viene fatto solo su controlli server personalizzati).

È possibile associare gli eventi in Page_Init o Page_Load, perché gli eventi di controllo sono triggerd dopo il caricamento di tutti i controlli ha finito. Il passaggio Load si verifica in modo top-bottom, prima nella pagina e quindi in modo ricorsivo in tutti i controlli figli.

Dopo il Load, i primi eventi attivati ​​sono Eventi di modifica, ad esempio TextChanged o SelectionChanged. Quindi vengono attivati ​​tutti gli altri eventi, come Click.

Se si vincono gli eventi in PreRender o Unload, non verrebbero attivati. Se hai fatto in Init o Load, sarebbero.

Così potrebbe sembrare che sia sicuro per legare in Init o Load, ma non è vero:

Potrebbe apparire come non c'è alcun motivo speciale per legarli sul Init o Load, perché faranno essere attivato in seguito nel ciclo di vita della pagina. Tuttavia, poiché l'associazione definita nello .aspx avviene durante lo Init, un programmatore si aspetta che tutti gli eventi siano già associati nell'evento Load. Cosa succederebbe se questo programmatore generasse un evento di controllo figlio nel codice? L'evento Load si verifica prima nella radice dell'albero di controllo e su tutti i bambini, in modo ricorsivo. Quindi, quando il programmatore sta tentando di aumentare l'evento del controllo figlio, non sarà già associato. Quindi questo non funzionerà come previsto. Questo è più che sufficiente da considerare non sicuro per associare eventi nell'evento Load. Ecco perché devi sempre associare gli eventi a Init.

Guardate questo diagramma per vedere l'ordine di esecuzione della pagina & bambini eventi: ASP.NET Page Life Cycle Diagram

Answer 2

Ho collegato il mio nel tag di controllo. Se lo faccio in questo modo è chiaro che è presente un gestore di eventi.

<asp:Button ID="btnRefresh" runat="server" Text="Refresh" OnClick="btnRefresh_Click" /> 

Se dovessi cablare un gestore di eventi nel codebehind, vorrei mettere in Page_Load come una chiamata di funzione privata.