Uno sviluppatore mi ha detto che utilizzavano i delegati per legare la maggior parte dei loro eventi in ASP.NET. Fino ad allora, non sapevo nemmeno che fosse possibile utilizzare i delegati in ASP.NET in modo significativo.
La mia comprensione è che ASP.NET/MVC3 funziona tramite verbi HTTP, non eventi / delegati. È persino possibile che un evento venga attivato dal client al server? Questo mi sembra una forma non valida di IPC.
I delegati vengono utilizzati in ASP.NET per collegare gli eventi dai controlli della pagina alle funzioni nel codice sottostante. Se prendiamo il pulsante ASP.NET ad esempio, abbiamo azione di clic, azione comando, azione DataBinding, insieme a Disposed, INit, Load, PreRender e Unload. Tutti hanno delegati associati a loro e se si crea una funzione che fa qualcosa con esso, il delegato indicherà la propria funzione.
Penso che la confusione sia quando usi i delegati. Poiché ASP.NET MVC3 è basato su ASP.NET e non è la sua bestia. Continuerai a utilizzare i delegati quando utilizzi i campi di input o uno qualsiasi dei controlli asp anche quando utilizzi MVC. Come maple_shaft dice :
Everytime there is a postback to the server, the ASP.NET lifecycle events are fired in order, causing the server side objects to be created, updating the viewstate with the updated information from the client, updating the server side elements with data from the viewstate, executing any server side events that need to be executed, and finally rendering the HTTP response to return back to the client.
Il modo in cui gli eventi vengono eseguiti è attraverso l'uso dei delegati.
Funziona tramite i verbi HTTP, ma anche il modello di eventi in ASP.NET è corretto.
ASP.NET tenta di astrarre le complessità sottostanti della comunicazione stateless HTTP in un modo che sarebbe facile da comprendere per gli sviluppatori WinForm e VB tradizionali. È discutibile se in realtà abbiano raggiunto questo obiettivo comunque.
Per ulteriori informazioni consultare l' articolo MSDN sul ciclo di vita di ASP.NET
ASP.NET colma il divario facendo esistere ciò che è noto come ViewState sia sulla sessione lato server che su un elemento DOM client. Ogni volta che viene inviato un postback al server, gli eventi del ciclo di vita di ASP.NET vengono attivati in ordine, causando la creazione degli oggetti lato server, l'aggiornamento del viewstate con le informazioni aggiornate dal client, l'aggiornamento degli elementi lato server con i dati dal viewstate , eseguendo qualsiasi evento sul lato server che deve essere eseguito e infine restituendo la risposta HTTP per tornare al client.
Il client a quel punto prenderà il viewstate aggiornato dal server e lo userà per aggiornare i propri elementi DOM ed eseguire gli eventi lato client come necessario.
Se sembra complesso è perché lo è. Questo è il motivo per cui molti lo considerano un fallimento perché richiede una comprensione dettagliata dell'architettura sottostante per diventare veramente bravo con esso.