Blazor-renderingslägen: praktisk guide

Före valet av renderingsläge

Vad Blazor egentligen är

Blazor är Microsofts komponentramverk för .NET webbappar. Du bygger användargränssnittet från Razor-komponenter, skriver mest interaktionslogik i C# och låter ASP.NET Core rendera dessa komponenter på servern, i WebAssembly eller inuti ett inbyggt appskal.

Det växte fram ur äldre ASP.NET-idéer. Web Forms försökte gömma webben bakom serverkontroller. MVC och Razor Pages gjorde HTML-renare för begäran-svar. Blazor lägger till återanvändbara interaktiva komponenter, men det gör inte MVC eller Razor Pages föråldrade för enkla innehållssidor och formulär.

Innan Blazor

Webbformulär, MVC och Razor Pages löste olika problem

Web Forms var produktivt men tungt och tillståndsfullt. MVC och Razor Pages gav renare HTML och enklare hantering av förfrågningar. De är fortfarande bra när en sida mestadels läser data, lägger upp ett formulär och returnerar HTML.

Vad Blazor lägger till

Komponenter håller UI-logiken nära markeringen

En Razor-komponent kan innehålla uppmärkning, parametrar, händelser, validering, injicerade tjänster och lokal stat. Det är användbart för instrumentpaneler, redigerare, guider, rutnät och verktyg där sidan ändras utan en fullständig omladdning.

Vad kom sedan

Modern .NET låter dig blanda renderingslägen

Nyare Blazor-appar kan kombinera statisk server-renderad HTML med interaktiva komponenter. Det är viktigt eftersom en sida kan behöva genomsökbart innehåll, medan en annan del behöver en live-komponent.

Innehållsförteckning

Börja här

Den användbara kortversionen

Blazor är inte en arkitektur. Det är en komponentmodell med flera renderingslägen. Rätt val beror mindre på syntax och mer på var tillstånd, latens, minne och genomsökningsbara länkar bor.

Server

Blazor Server är stateful

Det kan kännas snabbt vid första laddningen, men servern håller kretsar i live. Planera minnet, återanslut beteende och skala ut innan trafiken växer.

Webbläsare

WebAssembly betalar i förskott

Den tar bort live-serverkretsar, men det första besöket laddar ner runtime och app. Cache, trimning och förrendering av materia.

Infödd

Hybrid är ett produktbeslut

Använd Hybrid när appen verkligen behöver ett desktop- eller mobilskal. För offentligt innehåll, använd webbrendering och riktiga webbadresser.

Blazor Server

Blazor Server håller arbetet vid liv mellan klick

Blazor Server är inte en normal tillståndslös begäran-svar-sida. En ansluten webbläsarflik får en krets. Servern behåller komponenttillstånd och scoped-tjänster för den kretsen medan användaren är ansluten, och ofta under ett kort återanslutningsfönster efter en frånkoppling.

Minnet växer med aktiva kretsar

Varje ansluten flik har en krets. Komponenttillstånd, scoped services, valideringsstatus och väntande UI-arbete kan stanna i minnet tills kretsen tar slut. Belastningstester måste räkna aktiva användare, inte bara förfrågningar per sekund.

Latens blir en del av användargränssnittet

Ett knappklick, inmatningshändelse eller rutnätsinteraktion kan gå till servern och tillbaka. Värd nära användare och undvik chattiga komponenter när publiken är spridd över regioner.

Utskalning behöver en plan

Flera appinstanser behöver ofta klibbiga sessioner, ett SignalR-bakplan, Azure SignalR Service eller noggrann tillståndsdesign. Annars kan återanslutningar och strömförande kretsar landa på fel instans.

Bra passform: kontrollerade användare

Blazor Server är starkast för autentiserade verktyg, administratörsskärmar, instrumentpaneler och interna appar där användare, latens och värdkapacitet är kända.

Blazor WebAssembly

WebAssembly flyttar kostnaden till den första lasten

Blazor WebAssembly tar bort serverkretsar, men det tar inte bort kostnaden. Webbläsaren måste ladda ner .NET-runtime, sammansättningar, lokaliseringsresurser och apptillgångar innan upplevelsen känns snabb. Upprepade besök kan vara bra eftersom cachning hjälper. Första besök kräver vård.

Första belastningen är skatten

Webbläsaren laddar ner .NET-runtime, appsammansättningar, resurser och statiska tillgångar. Trimning hjälper. Kompilering i förväg kan förbättra CPU-tungt arbete men ökar ofta nedladdningsstorleken.

Hemligheter kan inte leva i klienten

En WebAssembly-app körs i användarens webbläsare. Behandla det som vilken offentlig frontend som helst: behåll hemligheter på servern, skydda API:er och anta att klientkoden kan inspekteras.

SEO behöver renderat innehåll

För offentliga artiklar, produktsidor och målsidor, lita inte på ett tomt skal som blir användbart först efter att WebAssembly startar. Använd rendering på serversidan, förrendering, statisk rendering eller en separat innehållssökväg.

Bra passform: offline eller klienttunga appar

WebAssembly fungerar bra när användare återvänder ofta, behöver offlinebeteende eller utför tungt arbete på klientsidan där en server tur och retur skulle vara värre.

Hybrid och WebView

Hybrid är för appar, inte för offentliga målsidor

Blazor Hybrid är användbart när ett .NET-team vill återanvända komponenter i en stationär eller mobilapp. Det körs i ett inbyggt skal genom en WebView, så det kan vara nära lokala filer, enhets-API:er och företagsdistribution. Det är inte en genväg för SEO-fokuserade webbplatser.

Använd Hybrid när du behöver tillgång till lokala filer, enhets-API:er, stationära distributioner eller mobilt paket.
Välj inte Hybrid endast för att återanvända webbkomponenter. Det inbyggda skalet lägger till uppdatering, lagring, signering och supportarbete.
För SEO och delbara offentliga webbadresser är Hybrid vanligtvis fel yta.

Flerspråkig routing

Kulturmedvetna länkar måste vara riktiga länkar

En flerspråkig Blazor-webbplats bör inte bygga språknavigering endast i klickhanterare eller JavaScript efter att sidan blivit interaktiv. Sökmotorer och användare behöver riktiga ankartaggar i den initiala HTML-koden, med stabila href-värden, kanoniska webbadresser och hreflang-data.

Använd centrala sidlänkar och hjälpare istället för handbyggda strängar som slash culture slash path.
Återge språklänkar som ankartaggar med href-värden under den första HTML-renderingen.
Håll kanoniska webbadresser, hreflang-webbadresser och synlig språknavigering synkroniserade.
Undvik att dölja viktiga länkar bakom onclick-hanterare, fördröjd JavaScript eller Blazor-tillstånd som endast är interaktivt.

Beslutsguide

Välj efter flaskhalsen du accepterar

Varje renderingsläge flyttar trycket till en annan plats. Välj det tryck du kan mäta, vara värd för och förklara för teamet.

Välj Server

När första laddningen och .NET-backend-integration är viktigast

Välj Blazor Server för kontrollerade autentiserade appar där serverminne, liveanslutningar och regional latens är acceptabla driftskostnader.

Välj WebAssembly

När klientarbete och offlinebeteende är viktigast

Välj WebAssembly när upprepade besök, cachning, offlineanvändning eller lokalt CPU-arbete är viktigare än den minsta första laddningen.

Välj Hybrid

När produkten verkligen är en inbyggd app

Välj Hybrid när applikationen hör hemma på dator eller mobil och behöver lokal integration mer än offentlig webbräckvidd.

Välj MVC eller Razor Pages

När sajten är mestadels dokument och blanketter

Klassiska ASP.NET Core MVC eller Razor Pages är ofta enklare för innehållstunga webbplatser, offentlig dokumentation och formulär med begränsad interaktivitet.

Referensavsnitt

Läs dessa härnäst när du bygger detta på riktigt

Dessa referenser är användbara efter arkitekturbeslutet, eftersom de täcker de delar som gör en Blazor-sida tillförlitlig i produktionen: metadata, språklänkar, värd och återanvändbart användargränssnitt.

Blazor SEO Metadata-komponent

Använd detta när varje sida behöver konsekvent titel, beskrivning, Open Graph, kanonisk och JSON-LD-utdata.

SEO-vänliga språk-/regionlänkar

Använd detta när flerspråkig routing kräver riktiga genomsökningsbara länkar, stabila kulturvägar och korrekt hreflang-utdata.

Hosta Blazor på UpCloud

Använd detta när en Blazor Server-app behöver en liten VPS, Nginx, TLS, systemd, loggar, säkerhetskopior och repeterbara distributioner.

TablerForNet

Använd detta när värdet är ett administratörsgränssnitt, datatabeller, formulär och instrumentpanelsskärmar istället för en marknadsföringssida.

Blazor

Använd Blazor-hubben när du vill ha de relaterade guiderna på ett ställe innan du väljer nästa implementeringsdetalj.

Vanliga frågor

Varför kan Blazor Server behöva mer minne än MVC?

MVC kan avsluta en begäran och släppa de flesta förfrågningar. Blazor Server håller en krets för varje ansluten webbläsarflik, så komponenttillstånd och scoped-tjänster kan hållas vid liv mellan klick.

Kan jag köra Blazor Server på flera appinstanser?

Ja, men planera det medvetet. Strömförande kretsar och SignalR-anslutningar behöver stabil routing, ett bakplan eller hanterad SignalR-tjänst och applikationstillstånd som överlever återansluter korrekt.

Kan Blazor WebAssembly vara SEO-vänlig?

Ja, men inte genom att skicka ett tomt skal och hoppas att sökroboten väntar. Offentliga sidor behöver renderad HTML, metadata, kanoniska länkar och strukturerad data före eller under det första svaret.

Hur ska flerspråkiga Blazor-länkar byggas?

Använd centrala ruttdefinitioner och rendera riktiga ankartaggar för varje kultur. Håll synliga länkar, kanoniska webbadresser och hreflang-data anpassade så att användare och sökrobotar ser samma språkstruktur.