Confronto tra le architetture di Web Forms ASP.NET 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.
Sebbene Web Forms ASP.NET e Blazorpresentino molti concetti simili, esistono delle differenze nel loro funzionamento. In questo capitolo vengono esaminati il funzionamento interno e le architetture di Web Forms ASP.NET e Blazor.
Web Form ASP.NET
Il framework Web Forms ASP.NET si basa su un'architettura incentrata sulle pagine. Ogni richiesta HTTP per una posizione 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:
- Markup HTML
- Codice C# o Visual Basic
- Classe code-behind contenente funzionalità di logica e gestione degli eventi
- Controlli
II controlli sono unità riutilizzabili dell'interfaccia utente Web che possono essere posizionate a livello di codice e con cui è possibile interagire 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 distribuiti come controlli utente. Un controllo utente deriva dalla classe UserControle ha una struttura simile a quella dell’oggetto Page. 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 compilati completamente con il codice, ereditando daWebControl o dalla classe di base CompositeControl.
Le pagine dispongono anche di un ciclo di vita esteso per gli eventi. Ogni pagina genera eventi per l'inizializzazione, il caricamento, il prerendering e lo scaricamento degli eventi che si verificano quando il runtime ASP.NET esegue il codice della pagina per ogni richiesta.
I controlli di un oggetto Page in genere eseguono il postback alla stessa pagina che ha presentato il controllo e portano con sé un payload da un campo modulo nascosto denominato ViewState. Il campo ViewState contiene informazioni sullo stato dei controlli nel momento in cui sono stati sottoposti a rendering e presentati nella pagina, consentendo al runtime ASP.NET di confrontare e identificare le modifiche apportate al contenuto inviato al server.
Blazor
Blazor è un framework di interfaccia utente Web lato client con caratteristiche simili ai framework front-end JavaScript come Angular o React. Blazor gestisce le interazioni utente ed esegue il rendering degli aggiornamenti necessari dell'interfaccia utente. Blazornon è basato su un modello request-reply. Le interazioni utente vengono gestite come eventi che non rientrano nel contesto di una determinata richiesta HTTP.
Le app Blazor sono costituite da uno o più componenti radice di cui viene eseguito il rendering in una pagina HTML.
Il modo in cui l'utente specifica dove deve essere eseguito il rendering dei componenti e le loro modalità di cablaggio è sono determinati dal modello di hosting.
BlazorIcomponenti 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 degli eventi per specifiche interazioni dell'utente in modo da aggiornare lo stato del componente.
In seguito alla gestione di un evento da parte di un componente, Blazor esegue il rendering del componente e tiene traccia delle modifiche apportate nell'output sottoposto a rendering. Il rendering dei componenti non viene eseguito direttamente nel DOM (Document Object Model). Eseguono invece il rendering in una rappresentazione in memoria del DOM denominata RenderTree in modo che Blazor possa tenere traccia delle modifiche. Blazor confronta l'output appena sottoposto a rendering con l'output precedente per calcolare una diff dell'interfaccia utente che viene quindi applicata in modo efficiente al DOM.
I componenti possono anche indicare manualmente che devono essere sottoposti a rendering se il loro stato cambia al di fuori di un normale evento dell'interfaccia utente. Blazor usa un SynchronizationContext per applicare un singolo thread logico di esecuzione. I metodi del ciclo di vita di un componente e tutti i callback di eventi generati da Blazor vengono eseguiti in questo SynchronizationContext.
