Confronto dell'architettura di ASP.NET Web Form e Blazor

Suggerimento

Questo contenuto è un estratto dell'eBook, Blazor per gli sviluppatori di Web Forms ASP.NET per Azure, disponibile in .NET Docs o come PDF scaricabile gratuitamente che può essere letto offline.

Scaricare il PDF

Anche se ASP.NET Web Form e Blazor hanno molti concetti simili, esistono differenze nel modo in cui funzionano. In questo capitolo vengono esaminate le funzioni e le architetture interne di ASP.NET Web Form e Blazor.

Web Form ASP.NET

Il framework Web Form ASP.NET si basa su un'architettura incentrata sulle pagine. Ogni richiesta HTTP per un percorso nell'app è una pagina separata con cui ASP.NET risponde. Quando vengono richieste pagine, il contenuto del browser viene sostituito con i risultati della pagina richiesta.

Le pagine sono costituite dai componenti seguenti:

• Linguaggio di markup HTML
• Codice C# o Visual Basic
• Classe di background di codice contenente la logica e le funzionalità di gestione degli eventi
• Controlli

I controlli sono unità riutilizzabili dell'interfaccia utente Web che possono essere posizionate e interagite a livello di codice in una pagina. Le pagine sono costituite da file che terminano con .aspx contenenti markup, controlli e codice. Le classi code-behind si trovano in file con lo stesso nome di base e un'estensione .aspx.cs o .aspx.vb , a seconda del linguaggio di programmazione usato. È interessante notare che il server Web interpreta il contenuto dei file .aspx e li compila ogni volta che cambiano. Questa ricompilazione si verifica anche se il server Web è già in esecuzione.

I controlli possono essere compilati con markup e recapitati come controlli utente. Un controllo utente deriva dalla UserControl classe e ha una struttura simile alla pagina. Il markup per i controlli utente viene archiviato in un file con estensione ascx . Una classe code-behind associata risiede in un file .ascx.cs o .ascx.vb . I controlli possono anche essere creati completamente con il codice, ereditando dalla classe di base WebControl o CompositeControl.

Le pagine hanno anche un ciclo di vita esteso per gli eventi. Ogni pagina genera eventi per l'inizializzazione, il caricamento, la pre-renderizzazione e lo scaricamento che si verificano quando il runtime ASP.NET esegue il codice della pagina per ogni richiesta.

I controlli su una pagina in genere rispondono alla stessa pagina che ha presentato il controllo e trasportano un payload da un campo modulo nascosto denominato ViewState. Il ViewState campo contiene informazioni sullo stato dei controlli al momento del rendering e della presentazione nella pagina, consentendo al runtime di ASP.NET di confrontare e identificare le modifiche nel contenuto inviato al server.

Blazor

Blazor è un framework dell'interfaccia utente Web sul lato client simile a quello dei framework front-end JavaScript come Angular o React. Blazor gestisce le interazioni utente ed esegue il rendering degli aggiornamenti necessari dell'interfaccia utente. Blazor non è basato su un modello richiesta-risposta. Le interazioni utente vengono gestite come eventi che non sono nel contesto di una determinata richiesta HTTP.

Blazor le app sono costituite da uno o più componenti radice di cui viene eseguito il rendering in una pagina HTML.

In che modo l'utente specifica dove renderizzare i componenti e come i componenti sono quindi configurati in base alle interazioni dell'utente è specifico del modello di hosting.

Blazor i componenti sono classi .NET che rappresentano una parte riutilizzabile dell'interfaccia utente. Ogni componente mantiene il proprio stato e specifica la propria logica di rendering, che può includere il rendering di altri componenti. I componenti specificano i gestori eventi per interazioni utente specifiche per aggiornare lo stato del componente.

Dopo che un componente gestisce un evento, Blazor esegue il rendering del componente e tiene traccia delle modifiche apportate nell'output sottoposto a rendering. I componenti non eseguono il rendering direttamente nel DOM (Document Object Model). Eseguono invece il rendering in una rappresentazione in memoria del DOM denominato , RenderTree in modo che Blazor possa tenere traccia delle modifiche. Blazor confronta l'output appena reso con l'output precedente per calcolare una differenza dell'interfaccia utente che viene quindi applicata in modo efficiente al DOM.

I componenti possono anche indicare manualmente che devono essere visualizzati se lo stato cambia all'esterno di un normale evento dell'interfaccia utente. Blazor utilizza SynchronizationContext per impiegare un singolo thread logico di esecuzione. I metodi del ciclo di vita di un componente e tutti i callback degli eventi generati da Blazor vengono eseguiti su questo SynchronizationContext.

PrecedenteAvanti