Guida pratica alle decisioni di Blazor
Blazor: server, WebAssembly o ibrido?
Blazor è utile quando si sa quale lavoro rimane nel server, quale lavoro si sposta nel browser e quali URL devono esistere come collegamenti HTML reali.
Questa guida salta la versione brochure. Si concentra sui compromessi che di solito sorprendono i team in seguito: memoria del server, connessioni live, latenza, dimensione del carico utile, SEO e routing multilingue.
Prima della scelta della modalità di rendering
Cos'è Blazor in realtà
Blazor è il framework dei componenti di Microsoft per le app Web .NET. Si crea l'interfaccia utente dai componenti Razor, si scrive la maggior parte della logica di interazione in C# e si consente ad ASP.NET Core di eseguire il rendering di tali componenti sul server, in WebAssembly o all'interno della shell di un'app nativa.
È nato da vecchie idee ASP.NET. Web Forms ha tentato di nascondere il Web dietro i controlli del server. MVC e Razor Pages hanno reso più pulito il codice HTML di richiesta-risposta. Blazor aggiunge componenti interattivi riutilizzabili, ma non rende MVC o Razor Pages obsoleti per moduli e pagine di contenuto semplici.
Web Forms, MVC e Razor Pages hanno risolto diversi problemi
Web Forms era produttivo ma pesante e con stato. MVC e Razor Pages hanno fornito un HTML più pulito e una gestione delle richieste più semplice. Sono ancora utili quando una pagina legge principalmente dati, pubblica un modulo e restituisce HTML.
I componenti mantengono la logica dell'interfaccia utente vicina al markup
Un componente Razor può contenere markup, parametri, eventi, convalida, servizi inseriti e stato locale. Ciò è utile per dashboard, editor, procedure guidate, griglie e strumenti in cui la pagina cambia senza un ricaricamento completo.
Il moderno .NET ti consente di mescolare le modalità di rendering
Le app Blazor più recenti possono combinare HTML statico con rendering del server con componenti interattivi. Ciò è importante perché una pagina potrebbe necessitare di contenuti scansionabili, mentre un'altra parte necessita di un componente live.
Indice
Inizia qui
L'utile versione breve
Blazor non è un'architettura. È un modello a un componente con diverse modalità di rendering. La scelta giusta dipende meno dalla sintassi e più da dove si trovano lo stato, la latenza, la memoria e i collegamenti scansionabili.
Blazor Server è con stato
Può sembrare veloce al primo caricamento, ma il server mantiene i circuiti attivi. Pianifica la memoria, il comportamento di riconnessione e la scalabilità orizzontale prima che il traffico aumenti.
WebAssembly paga in anticipo
Rimuove i circuiti del server live, ma alla prima visita vengono scaricati il runtime e l'app. Memorizza nella cache, ritaglia e prerendering.
L'ibrido è una decisione sul prodotto
Utilizza Hybrid quando l'app necessita davvero di una shell desktop o mobile. Per i contenuti pubblici, utilizza il rendering web e URL reali.
Blazor Server
Blazor Server mantiene vivo il lavoro tra un clic e l'altro
Blazor Server non è una normale pagina di richiesta-risposta senza stato. Una scheda del browser connessa ottiene un circuito. Il server mantiene lo stato dei componenti e i servizi con ambito per quel circuito mentre l'utente è connesso e spesso per una breve finestra di riconnessione dopo una disconnessione.
La memoria cresce con i circuiti attivi
Ogni scheda collegata ha un circuito. Lo stato del componente, i servizi con ambito, lo stato di convalida e il lavoro dell'interfaccia utente in sospeso possono rimanere in memoria fino al termine del circuito. I test di carico devono contare gli utenti attivi, non solo le richieste al secondo.
La latenza diventa parte dell'interfaccia utente
Un clic su un pulsante, un evento di input o un'interazione sulla griglia possono viaggiare verso il server e viceversa. Ospita vicino agli utenti ed evita componenti loquaci quando il pubblico è distribuito in più regioni.
Lo scale-out necessita di un piano
Più istanze dell'app spesso richiedono sessioni permanenti, un backplane SignalR, il servizio Azure SignalR o un'attenta progettazione dello stato. Altrimenti si riconnette e i circuiti sotto tensione possono finire nell'istanza sbagliata.
Buona vestibilità: utenti controllati
Blazor Server è più potente per strumenti autenticati, schermate di amministrazione, dashboard e app interne in cui sono noti utenti, latenza e capacità di hosting.
Blazor WebAssembly
WebAssembly sposta il costo al primo caricamento
Blazor WebAssembly rimuove i circuiti del server, ma non rimuove i costi. Il browser deve scaricare il runtime .NET, gli assembly, le risorse di localizzazione e le risorse dell'app affinché l'esperienza risulti veloce. Le visite ripetute possono essere utili perché la memorizzazione nella cache aiuta. Le prime visite necessitano di cure.
Il primo carico è la tassa
Il browser scarica il runtime .NET, gli assembly dell'app, le risorse e le risorse statiche. Il taglio aiuta. La compilazione anticipata può migliorare il lavoro pesante della CPU ma spesso aumenta le dimensioni del download.
I segreti non possono vivere nel client
Un'app WebAssembly viene eseguita nel browser dell'utente. Trattalo come qualsiasi frontend pubblico: mantieni i segreti sul server, proteggi le API e presumi che il codice client possa essere ispezionato.
La SEO ha bisogno di contenuti renderizzati
Per articoli pubblici, pagine di prodotto e pagine di destinazione, non fare affidamento su una shell vuota che diventa utile solo dopo l'avvio di WebAssembly. Utilizza il rendering lato server, il prerendering, il rendering statico o un percorso del contenuto separato.
Buona soluzione: app offline o con client pesanti
WebAssembly funziona bene quando gli utenti ritornano spesso, necessitano di un comportamento offline o svolgono un lavoro pesante sul lato client in cui un viaggio di andata e ritorno sul server sarebbe peggiore.
Ibrido e WebView
L'ibrido è per le app, non per le pagine di destinazione pubbliche
Blazor Hybrid è utile quando un team .NET vuole riutilizzare i componenti all'interno di un'app desktop o mobile. Funziona in una shell nativa tramite WebView, quindi può essere vicino a file locali, API del dispositivo e distribuzione aziendale. Non è una scorciatoia per i siti web incentrati sulla SEO.
- Utilizza Hybrid quando hai bisogno di accedere a file locali, API del dispositivo, distribuzione desktop o pacchetti per dispositivi mobili.
- Non scegliere Hybrid solo per riutilizzare componenti web. La shell nativa aggiunge attività di aggiornamento, archiviazione, firma e supporto.
- Per la SEO e gli URL pubblici condivisibili, l'ibrido è solitamente la superficie sbagliata.
Routing multilingue
I collegamenti consapevoli della cultura devono essere collegamenti reali
Un sito Blazor multilingue non deve creare la navigazione in lingua solo nei gestori dei clic o in JavaScript dopo che la pagina diventa interattiva. I motori di ricerca e gli utenti necessitano di tag di ancoraggio reali nell'HTML iniziale, con valori href stabili, URL canonici e dati hreflang.
- Utilizza collegamenti e helper alla pagina centrale invece di stringhe create manualmente come slash culture slash path.
- Visualizza i collegamenti linguistici come tag di ancoraggio con valori href durante il rendering HTML iniziale.
- Mantieni sincronizzati gli URL canonici, gli URL hreflang e la navigazione nella lingua visibile.
- Evitare di nascondere collegamenti importanti dietro gestori onclick, JavaScript ritardato o stato Blazor solo interattivo.
Guida alla scelta
Scegli in base al collo di bottiglia che accetti
Ogni modalità di rendering sposta la pressione in un luogo diverso. Scegli la pressione che puoi misurare, ospitare e spiegare al team.
Quando il primo caricamento e l'integrazione del backend .NET contano di più
Scegli Blazor Server per app autenticate controllate in cui la memoria del server, le connessioni live e la latenza regionale rappresentano costi operativi accettabili.
Quando il lavoro del cliente e il comportamento offline contano di più
Scegli WebAssembly quando le visite ripetute, la memorizzazione nella cache, l'utilizzo offline o il lavoro della CPU locale sono più importanti del primo caricamento più piccolo.
Quando il prodotto è davvero un'app nativa
Scegli l'ibrido quando l'applicazione appartiene al desktop o al dispositivo mobile e necessita di integrazione locale più che di copertura web pubblica.
Quando il sito contiene principalmente documenti e moduli
Le classiche ASP.NET Core MVC o Razor Pages sono spesso più semplici per siti con molti contenuti, documentazione pubblica e moduli con interattività limitata.
Sezione di riferimento
Leggili dopo quando lo costruirai per davvero
Questi riferimenti sono utili dopo la decisione sull'architettura, perché coprono le parti che rendono affidabile una pagina Blazor in produzione: metadati, collegamenti linguistici, hosting e interfaccia utente riutilizzabile.
Utilizzalo quando ogni pagina necessita di titolo, descrizione, output Open Graph, canonico e JSON-LD coerenti.
Link lingua-regione SEO-friendlyUtilizzalo quando il routing multilingue richiede collegamenti reali scansionabili, percorsi culturali stabili e output hreflang corretto.
Ospita Blazor su UpCloudUsarlo quando un'app Blazor Server necessita di un piccolo VPS, Nginx, TLS, systemd, log, backup e distribuzioni ripetibili.
TablerForNetUtilizzalo quando il valore è un'interfaccia di amministrazione, tabelle di dati, moduli e schermate del dashboard anziché una pagina di marketing.
BlazorUsare l'hub Blazor quando si vogliono le guide correlate in un unico posto prima di scegliere il successivo dettaglio di implementazione.
Domande frequenti
Perché Blazor Server può richiedere più memoria di MVC?
MVC può completare una richiesta e rilasciare la maggior parte dello stato della richiesta. Blazor Server mantiene un circuito per ogni scheda del browser connessa, in modo che lo stato dei componenti e i servizi con ambito possano rimanere attivi tra un clic e l'altro.
Posso eseguire Blazor Server su più istanze dell'app?
Sì, ma pianificalo deliberatamente. I circuiti attivi e le connessioni SignalR richiedono un routing stabile, un backplane o un servizio SignalR gestito e uno stato dell'applicazione che sopravviva alla riconnessione corretta.
Blazor WebAssembly può essere SEO-friendly?
Sì, ma non spedendo un guscio vuoto e sperando che il crawler aspetti. Le pagine pubbliche necessitano di rendering HTML, metadati, collegamenti canonici e dati strutturati prima o durante la prima risposta.
Come devono essere creati i collegamenti Blazor multilingue?
Utilizza definizioni di percorso centrali e visualizza tag di ancoraggio reali per ciascuna cultura. Mantieni allineati i collegamenti visibili, gli URL canonici e i dati hreflang in modo che utenti e crawler vedano la stessa struttura linguistica.