ASP.NET Modelli di hosting Core Blazor

Questo articolo illustra i modelli di hosting, incentrati Blazor principalmente sulle Blazor Server app e Blazor WebAssembly nelle versioni di .NET precedenti a .NET 8. Le indicazioni contenute in questo articolo sono rilevanti in tutte le versioni .NET per Blazor Hybrid le app eseguite su piattaforme native per dispositivi mobili e desktop. Blazor Web Apps in .NET 8 o versione successiva sono concettualizzati meglio dal Razor modo in cui viene eseguito il rendering dei componenti, descritto come modalità di rendering. Le modalità di rendering sono descritte brevemente nell'articolo Panoramica dei concetti fondamentali e descritte in dettaglio in ASP.NET Blazor modalità di rendering core del nodo Componenti .

Blazor è un framework Web per la creazione di componenti dell'interfaccia utente Web (Razor componenti) che possono essere ospitati in modi diversi. Razor I componenti possono eseguire lato server in ASP.NET Core (Blazor Server) rispetto al lato client nel browser in un runtime .NET basato su WebAssembly (Blazor WebAssembly, Blazor WASM). È anche possibile ospitare Razor componenti in app native per dispositivi mobili e desktop che eseguono il rendering in un controllo incorporato Web View (Blazor Hybrid). Indipendentemente dal modello di hosting, la modalità di compilazione Razor dei componenti è la stessa. Gli stessi Razor componenti possono essere usati con uno qualsiasi dei modelli di hosting invariati.

Blazor Server

Con il Blazor Server modello di hosting, i componenti vengono eseguiti nel server dall'interno di un'app ASP.NET Core. Gli aggiornamenti dell'interfaccia utente, la gestione degli eventi e le chiamate JavaScript vengono gestiti tramite una SignalR connessione tramite il protocollo WebSocket. Lo stato del server associato a ogni client connesso viene chiamato circuito. I circuiti non sono associati a una connessione di rete specifica e possono tollerare interruzioni di rete temporanee e tentativi dal client di riconnettersi al server quando la connessione viene persa.

In un'app con rendering server tradizionale, l'apertura della stessa app in più schermate del browser (schede o iframes) in genere non si traduce in richieste di risorse aggiuntive nel server. Per il modello di hosting, ogni schermata del Blazor Server browser richiede un circuito separato e istanze separate dello stato del componente gestito dal server. Blazor considera la chiusura di una scheda del browser o il passaggio a un URL esterno con terminazione normale . In caso di terminazione normale, il circuito e le risorse associate vengono immediatamente rilasciati. Un client può anche disconnettersi in modo non normale, ad esempio a causa di un'interruzione della rete. Blazor Server archivia circuiti disconnessi per un intervallo configurabile per consentire al client di riconnettersi.

Nel client, lo Blazor script stabilisce la SignalR connessione con il server. Lo script viene gestito da una risorsa incorporata nel framework condiviso ASP.NET Core.

Il Blazor Server modello di hosting offre diversi vantaggi:

• Le dimensioni del download sono notevolmente inferiori rispetto a quando viene usato il Blazor WebAssembly modello di hosting e l'app viene caricata molto più velocemente.
• L'app sfrutta appieno le funzionalità del server, incluso l'uso delle API .NET Core.
• .NET Core nel server viene usato per eseguire l'app, quindi gli strumenti .NET esistenti, ad esempio il debug, funzionano come previsto.
• I thin client sono supportati. Ad esempio, Blazor Server funziona con i browser che non supportano WebAssembly e nei dispositivi con vincoli di risorse.
• La codebase dell’app .NET/C#, incluso il codice di componente dell'app, non viene fornita ai client.

Il Blazor Server modello di hosting presenta le limitazioni seguenti:

• In genere esiste una latenza più elevata. Ogni interazione dell'utente comporta un hop di rete.
• Non è disponibile alcun supporto offline. Se la connessione client non riesce, l'interattività ha esito negativo.
• Il ridimensionamento delle app con molti utenti richiede risorse server per gestire più connessioni client e stato client.
• Per gestire l'app è necessario un server ASP.NET Core. Gli scenari di distribuzione serverless non sono possibili, ad esempio la gestione dell'app da un rete per la distribuzione di contenuti (RETE CDN).

È consigliabile usare il servizio di Azure SignalR per le app che adottano il Blazor Server modello di hosting. Il servizio consente di aumentare le prestazioni di un'app Blazor Server a un numero elevato di connessioni simultanee SignalR .

Blazor WebAssembly

Il Blazor WebAssembly modello di hosting esegue componenti sul lato client nel browser in un runtime .NET basato su WebAssembly. Razor i componenti, le relative dipendenze e il runtime .NET vengono scaricati nel browser. I componenti vengono eseguiti direttamente nel thread dell'interfaccia utente del browser. Gli aggiornamenti dell'interfaccia utente e la gestione degli eventi vengono eseguiti nello stesso processo. Gli asset vengono distribuiti come file statici in un server Web o un servizio in grado di gestire contenuto statico ai client.

Blazor Le app Web possono usare il modello di hosting per abilitare l'interattività Blazor WebAssembly lato client. Quando viene creata un'app che viene eseguita esclusivamente nel Blazor WebAssembly modello di hosting senza rendering lato server e interattività, l'app viene chiamata app autonomaBlazor WebAssembly .

Quando un'app autonoma Blazor WebAssembly usa un'app back-end ASP.NET Core per gestire i file, l'app viene chiamata app ospitataBlazor WebAssembly . Usando , Blazor WebAssemblysi ottiene un'esperienza di sviluppo Web full-stack con .NET, inclusa la possibilità di condividere il codice tra le app client e server, il supporto per la pre-gestione e l'integrazione con MVC e Razor Pages. Un'app client ospitata può interagire con l'app server back-end in rete usando un'ampia gamma di framework e protocolli di messaggistica, ad esempio API Web, gRPC-web e SignalR (usare ASP.NET Core SignalR con Blazor).

Un'app Blazor WebAssembly compilata come app Web progressiva (PWA) usa api del browser moderne per abilitare molte delle funzionalità di un'app client nativa, ad esempio lavorare offline, in esecuzione nella propria finestra dell'app, avviare dal sistema operativo dell'host, ricevere notifiche push e aggiornare automaticamente in background.

Lo Blazor script gestisce:

• Download del runtime, Razor dei componenti e delle dipendenze del componente.
• Inizializzazione del runtime.

La dimensione dell'app pubblicata, ovvero la dimensione del payload, è un fattore cruciale per le prestazioni ai fini dell'usabilità dell'app. Un'app di grandi dimensioni impiega relativamente molto tempo a essere scaricata in un browser, influendo negativamente sull'esperienza utente. Blazor WebAssembly consente di ottimizzare le dimensioni del payload per ridurre i tempi di download:

• Il codice non usato viene rimosso dall'app quando questa viene pubblicata dal trimmer del linguaggio intermedio.
• Le risposte HTTP vengono compresse.
• Il runtime e gli assembly .NET vengono memorizzati nella cache nel browser.

Il Blazor WebAssembly modello di hosting offre diversi vantaggi:

• Per le app autonome Blazor WebAssembly , non esiste alcuna dipendenza lato server .NET dopo il download dell'app dal server, quindi l'app rimane funzionale se il server passa offline.
• Le risorse e le funzionalità client vengono sfruttate completamente.
• Il lavoro viene scaricato dal server al client.
• Per le app autonome Blazor WebAssembly , non è necessario un server Web ASP.NET Core per ospitare l'app. Gli scenari di distribuzione serverless sono possibili, ad esempio la gestione dell'app da una rete CDN (rete per la distribuzione di contenuti).

Il Blazor WebAssembly modello di hosting presenta le limitazioni seguenti:

• Razor i componenti sono limitati alle funzionalità del browser.
• È necessario l'hardware client e il software in grado di supportare (ad esempio, supporto WebAssembly).
• Le dimensioni del download sono maggiori e il caricamento dei componenti richiede più tempo.
• Il codice inviato al client non può essere protetto dall'ispezione e dalla manomissione da parte degli utenti.

L'interprete .NET Intermediate Language (IL) include il supporto parziale del runtime JIT (Just-In-Time) per ottenere prestazioni di runtime migliorate. L'interprete JIT ottimizza l'esecuzione dei bytecode dell'interprete sostituendoli con BLOB di codice WebAssembly di piccole dimensioni. L'interprete JIT viene abilitato automaticamente per Blazor WebAssembly le app tranne durante il debug.

Blazor supporta la compilazione anticipata (AOT), in cui è possibile compilare il codice .NET direttamente in WebAssembly. La compilazione AOT comporta miglioramenti delle prestazioni di runtime a scapito di dimensioni maggiori dell'app. Per altre informazioni, vedere ASP.NET Compilazione di core Blazor WebAssembly e compilazione anticipata (AOT).

Gli stessi strumenti di compilazione WebAssembly .NET usati per la compilazione AOT ricollegano anche il runtime .NET WebAssembly per ridurre il codice di runtime inutilizzato. Blazor elimina anche il codice inutilizzato dalle librerie .NET Framework. Il compilatore .NET precomprime ulteriormente un'app autonoma Blazor WebAssembly per un payload di app più piccolo.

I componenti di cui è stato eseguito Razor il rendering di WebAssembly possono usare le dipendenze native compilate per l'esecuzione in WebAssembly.

Blazor Hybrid

Blazor può anche essere usato per creare app client native usando un approccio ibrido. Le app ibride sono app native che sfruttano le tecnologie Web per le funzionalità. In un'app Blazor Hybrid , Razor i componenti vengono eseguiti direttamente nell'app nativa (non in WebAssembly) insieme a qualsiasi altro codice .NET ed esegue il rendering dell'interfaccia utente Web in base a HTML e CSS a un controllo incorporato Web View tramite un canale di interoperabilità locale.

Blazor HybridLe app possono essere compilate usando diversi framework di app native .NET, tra cui .NET MAUI, WPF e Windows Form. Blazor fornisce BlazorWebView controlli per l'aggiunta Razor di componenti alle app compilate con questi framework. L'uso Blazor di con .NET MAUI offre un modo pratico per creare app multipiattaforma Blazor Hybrid per dispositivi mobili e desktop, mentre Blazor l'integrazione con WPF e Windows Form può essere un ottimo modo per modernizzare le app esistenti.

Poiché Blazor Hybrid le app sono app native, possono supportare funzionalità non disponibili solo con la piattaforma Web. Blazor Hybrid le app hanno accesso completo alle funzionalità della piattaforma nativa tramite le normali API .NET. Blazor Hybridle app possono anche condividere e riutilizzare componenti con app o Blazor WebAssembly esistentiBlazor Server. Blazor Hybrid le app combinano i vantaggi del Web, delle app native e della piattaforma .NET.

Il Blazor Hybrid modello di hosting offre diversi vantaggi:

• Riutilizzare i componenti esistenti che possono essere condivisi tra dispositivi mobili, desktop e Web.
• Sfruttare le competenze, l'esperienza e le risorse di sviluppo Web.
• Le app hanno accesso completo alle funzionalità native del dispositivo.

Il Blazor Hybrid modello di hosting presenta le limitazioni seguenti:

• Le app client native separate devono essere compilate, distribuite e gestite per ogni piattaforma di destinazione.
• Le app client native richiedono in genere più tempo per trovare, scaricare e installare l'accesso a un'app Web in un browser.

Per altre informazioni, vedere ASP.NET CoreBlazor Hybrid.

Per altre informazioni sui framework client nativi Microsoft, vedere le risorse seguenti:

• .NET Multi-platform App UI (.NET MAUI)
• WPF (Windows Presentation Foundation)
• WinForms

Quale Blazor modello di hosting è necessario scegliere?

Il modello di hosting di un componente viene impostato in base alla modalità di rendering, in fase di compilazione o in fase di esecuzione, descritta con esempi nelle modalità di rendering di ASP.NET CoreBlazor. La tabella seguente illustra le considerazioni principali per l'impostazione della modalità di rendering per determinare il modello di hosting di un componente. Per le app autonome Blazor WebAssembly , il rendering di tutti i componenti dell'app viene eseguito nel client con il Blazor WebAssembly modello di hosting.

Blazor Hybridle app includono .NET MAUI, WPF e app framework Windows Form.

Funzionalità	Blazor Server	Blazor WebAssembly (WASM)	Blazor Hybrid
Completare la compatibilità dell'API .NET	✔️Sostenuto	❌Non supportato	✔️Sostenuto
Accesso diretto alle risorse server e di rete	✔️Sostenuto	❌Non supportato†	❌Non supportato†
Piccole dimensioni del payload con tempi di caricamento iniziali rapidi	✔️Sostenuto	❌Non supportato	❌Non supportato
Velocità di esecuzione quasi nativa	✔️Sostenuto	✔️Supportato*	✔️Sostenuto
Codice dell'app sicuro e privato nel server	✔️Sostenuto	❌Non supportato†	❌Non supportato†
Eseguire le app offline dopo il download	❌Non supportato	✔️Sostenuto	✔️Sostenuto
Hosting di siti statici	❌Non supportato	✔️Sostenuto	❌Non supportato
Offload dell'elaborazione ai client	❌Non supportato	✔️Sostenuto	✔️Sostenuto
Accesso completo alle funzionalità client native	❌Non supportato	❌Non supportato	✔️Sostenuto
Distribuzione basata sul Web	✔️Sostenuto	✔️Sostenuto	❌Non supportato

Blazor WebAssembly† e Blazor Hybrid le app possono usare API basate su server per accedere alle risorse server/di rete e accedere al codice dell'app privato e sicuro.
*Blazor WebAssembly raggiunge solo prestazioni quasi native con compilazione AOT (Ahead-of-Time).

Dopo aver scelto il modello di hosting dell'app, è possibile generare un'app Blazor Server o Blazor WebAssembly da un Blazor modello di progetto. Per altre informazioni, vedere Strumenti per ASP.NET Core Blazor.

Per creare un'appBlazor Hybrid, vedere gli articoli in ASP.NET esercitazioni di baseBlazor Hybrid.

Completare la compatibilità dell'API .NET

I componenti sottoposti a rendering per il Blazor Server modello di hosting e Blazor Hybrid le app hanno una compatibilità completa delle API .NET, mentre i componenti sottoposti a rendering per Blazor WebAssembly sono limitati a un subset di API .NET. Quando la specifica di un'app richiede una o più API .NET non disponibili per i componenti sottoposti a rendering WebAssembly, scegliere di eseguire il rendering dei componenti per Blazor Server o usare Blazor Hybrid.

Accesso diretto alle risorse server e di rete

I componenti di cui viene eseguito il rendering per il Blazor Server modello di hosting hanno accesso diretto alle risorse server e di rete in cui è in esecuzione l'app. Poiché i componenti ospitati usando Blazor WebAssembly o Blazor Hybrid vengono eseguiti in un client, non hanno accesso diretto alle risorse server e di rete. I componenti possono accedere indirettamente alle risorse di server e di rete tramite API protette basate su server. Le API basate su server potrebbero essere disponibili tramite librerie, pacchetti e servizi di terze parti. Tenere conto delle considerazioni seguenti:

• Le librerie, i pacchetti e i servizi di terze parti potrebbero essere costosi per implementare e gestire, supportando in modo debole o introducendo rischi per la sicurezza.
• Se una o più API basate su server vengono sviluppate internamente dall'organizzazione, sono necessarie risorse aggiuntive per compilarle e gestirle.

Usare il Blazor Server modello di hosting per evitare la necessità di esporre le API dall'ambiente server.

Piccole dimensioni del payload con tempi di caricamento iniziali rapidi

Il rendering dei componenti dal server riduce le dimensioni del payload dell'app e migliora i tempi di caricamento iniziali. Quando si desidera un tempo di caricamento iniziale rapido, usare il modello di hosting o prendere in considerazione il Blazor Server rendering statico sul lato server.

Velocità di esecuzione quasi nativa

Blazor Hybrid le app vengono eseguite usando il runtime .NET in modo nativo nella piattaforma di destinazione, che offre la migliore velocità possibile.

I componenti sottoposti a rendering per il Blazor WebAssembly modello di hosting, inclusi i App Web progressivi (PWA) e le app autonome Blazor WebAssembly vengono eseguite usando il runtime .NET per WebAssembly, che è più lento rispetto all'esecuzione direttamente nella piattaforma. Prendere in considerazione l'uso di AOT (Ahead-of-Time) compilato per migliorare le prestazioni di runtime quando si usa Blazor WebAssembly.

Codice dell'app sicuro e privato nel server

La gestione del codice dell'app in modo sicuro e privato nel server è una funzionalità predefinita dei componenti di cui viene eseguito il rendering per il Blazor Server modello di hosting. I componenti di cui viene eseguito il rendering usando i Blazor WebAssembly modelli di hosting o Blazor Hybrid possono usare le API basate su server per accedere alle funzionalità che devono essere mantenute private e sicure. Si applicano le considerazioni per lo sviluppo e la gestione di API basate su server descritte nella sezione Accesso diretto alle risorse di server e di rete. Se lo sviluppo e la manutenzione delle API basate su server non è consigliabile per mantenere il codice dell'app sicuro e privato, eseguire il rendering dei componenti per il Blazor Server modello di hosting.

Eseguire le app offline dopo il download

Le app autonome Blazor WebAssembly create come progressive App Web (PWA) e Blazor Hybrid le app possono essere eseguite offline, particolarmente utili quando i client non sono in grado di connettersi a Internet. Il rendering dei componenti per il Blazor Server modello di hosting non riesce quando la connessione al server viene persa. Se un'app deve essere eseguita offline, autonoma Blazor WebAssembly e Blazor Hybrid sono le scelte migliori.

Hosting di siti statici

L'hosting di siti statici è possibile con le app autonome Blazor WebAssembly perché vengono scaricate nei client come set di file statici. Le app autonome Blazor WebAssembly non richiedono che un server esegua codice lato server per scaricare ed eseguire e possa essere recapitato tramite una rete CDN (rete per la distribuzione di contenuti), ad esempio Rete CDN di Azure.

Anche se Blazor Hybrid le app vengono compilate in uno o più asset di distribuzione autonomi, gli asset vengono in genere forniti ai client tramite un app store di terze parti. Se l'hosting statico è un requisito dell'app, selezionare autonomo Blazor WebAssembly.

Offload dell'elaborazione ai client

Blazor WebAssembly e Blazor Hybrid le app vengono eseguite sui client e quindi offload dell'elaborazione ai client. Blazor Server le app vengono eseguite in un server, quindi la domanda di risorse server aumenta in genere con il numero di utenti e la quantità di elaborazione necessaria per utente. Quando è possibile eseguire l'offload della maggior parte o di tutte le elaborazioni di un'app ai client e l'app elabora una quantità significativa di dati Blazor WebAssembly o Blazor Hybrid è la scelta migliore.

Accesso completo alle funzionalità client native

Blazor Hybrid Le app hanno accesso completo alle funzionalità API client native tramite framework di app native .NET. Nelle Blazor Hybrid app i Razor componenti vengono eseguiti direttamente nell'app nativa, non in WebAssembly. Quando le funzionalità client complete sono un requisito, Blazor Hybrid è la scelta migliore.

Distribuzione basata sul Web

Blazor Le app Web vengono aggiornate al successivo aggiornamento dell'app dal browser.

Blazor Hybrid le app sono app client native che in genere richiedono un programma di installazione e un meccanismo di distribuzione specifico della piattaforma.

Impostazione del modello di hosting di un componente

Per impostare il modello di hosting di un componente su Blazor Server o Blazor WebAssembly in fase di compilazione o dinamicamente in fase di esecuzione, impostarne la modalità di rendering. Le modalità di rendering sono descritte e illustrate in modo completo nell'articolo ASP.NET Modalità di rendering coreBlazor. Non è consigliabile passare direttamente da questo articolo alle modalità di rendering senza leggere il contenuto negli articoli tra questi due articoli. Ad esempio, le modalità di rendering sono più facilmente comprensibili esaminando Razor esempi di componenti, ma la struttura e la funzione dei componenti di base Razor non vengono trattate fino a quando non viene raggiunto l'articolo nozioni fondamentali di base di ASP.NETBlazor. È anche utile conoscere Blazori modelli di progetto e gli strumenti prima di usare gli esempi di componenti nell'articolo Modalità di rendering.