Välj mellan traditionella webbappar och ensidesappar (SPA)
Dricks
Det här innehållet är ett utdrag från eBook, Architect Modern Web Applications med ASP.NET Core och Azure, som finns på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.
"Atwood's Law: Alla program som kan skrivas i JavaScript, kommer så småningom att skrivas i JavaScript."
- Jeff Atwood
Det finns två allmänna metoder för att skapa webbprogram idag: traditionella webbprogram som utför det mesta av programlogik på servern och ensidesprogram (SPA) som utför det mesta av användargränssnittslogik i en webbläsare och kommunicerar med webbservern främst med hjälp av webb-API:er. En hybridmetod är också möjlig, den enklaste är värd för en eller flera omfattande SPA-liknande underprogram i ett större traditionellt webbprogram.
Använd traditionella webbprogram när:
Programmets krav på klientsidan är enkla eller till och med skrivskyddade.
Programmet måste fungera i webbläsare utan JavaScript-stöd.
Ditt program är offentligt och drar nytta av sökmotoridentifiering och hänvisningar.
Använd ett SPA när:
Ditt program måste exponera ett omfattande användargränssnitt med många funktioner.
Ditt team är bekant med JavaScript, TypeScript eller BlazorWebAssembly utveckling.
Ditt program måste redan exponera ett API för andra (interna eller offentliga) klienter.
Dessutom kräver SPA-ramverk större arkitektur- och säkerhetsexpertis. De får större omsättning på grund av frekventa uppdateringar och nya klientramverk än traditionella webbprogram. Det kan vara svårare med SPA-program än traditionella webbappar att konfigurera automatiserade bygg- och distributionsprocesser och använda distributionsalternativ som containrar.
Förbättringar av användarupplevelsen som möjliggörs av SPA-metoden måste vägas mot dessa överväganden.
Blazor
ASP.NET Core innehåller en modell för att skapa omfattande, interaktiva och komposterbara användargränssnitt med namnet Blazor. Blazor På serversidan kan utvecklare skapa användargränssnitt med C# och Razor på servern och för att användargränssnittet ska vara interaktivt anslutet till webbläsaren i realtid med hjälp av en beständig SignalR-anslutning. BlazorWebAssemblyintroducerar ett annat alternativ för Blazor appar, så att de kan köras i webbläsaren med .WebAssembly Eftersom det är verklig .NET-kod som körs på WebAssemblykan du återanvända kod och bibliotek från delar av programmet på serversidan.
Blazor ger ett nytt, tredje alternativ att överväga när du utvärderar om du vill skapa ett rent server-renderat webbprogram eller ett SPA. Du kan skapa omfattande, SPA-liknande beteenden på klientsidan med , Blazorutan att behöva betydande JavaScript-utveckling. Blazor program kan anropa API:er för att begära data eller utföra åtgärder på serversidan. De kan samverka med JavaScript om det behövs för att dra nytta av JavaScript-bibliotek och ramverk.
Överväg att skapa ditt webbprogram med Blazor när:
Ditt program måste exponera ett omfattande användargränssnitt
Ditt team är mer bekvämt med .NET-utveckling än JavaScript- eller TypeScript-utveckling
Om du har ett befintligt webbformulärsprogram som du överväger att migrera till .NET Core eller den senaste .NET kanske du vill granska den kostnadsfria e-boken så Blazor att webbformulärutvecklare kan se om det är lämpligt att överväga att migrera den till Blazor.
Mer information om Blazorfinns i Kom igång med Blazor.
När du ska välja traditionella webbappar
Följande avsnitt är en mer detaljerad förklaring av de tidigare angivna orsakerna till att välja traditionella webbprogram.
Ditt program har enkla, möjligen skrivskyddade krav på klientsidan
Många webbprogram används främst på ett skrivskyddat sätt av de allra flesta användare. Skrivskyddade (eller skrivskyddade) program tenderar att vara mycket enklare än de program som underhåller och manipulerar en hel del tillstånd. En sökmotor kan till exempel bestå av en enda startpunkt med en textruta och en andra sida för att visa sökresultat. Anonyma användare kan enkelt göra begäranden och det finns inte mycket behov av logik på klientsidan. På samma sätt består ett blogg- eller innehållshanteringssystems offentliga program vanligtvis huvudsakligen av innehåll med lite beteende på klientsidan. Sådana program skapas enkelt som traditionella serverbaserade webbprogram, som utför logik på webbservern och renderar HTML som ska visas i webbläsaren. Det faktum att varje unik sida på webbplatsen har en egen URL som kan bokmärks och indexeras av sökmotorer (som standard, utan att behöva lägga till den här funktionen som en separat funktion i programmet) är också en tydlig fördel i sådana scenarier.
Ditt program måste fungera i webbläsare utan JavaScript-stöd
Webbprogram som behöver fungera i webbläsare med begränsat eller inget JavaScript-stöd bör skrivas med traditionella arbetsflöden för webbappar (eller åtminstone kunna återgå till sådant beteende). SPA:erna kräver JavaScript på klientsidan för att fungera. Om den inte är tillgänglig är SPA:er inte ett bra val.
Ditt team känner inte till JavaScript- eller TypeScript-utvecklingstekniker
Om ditt team inte är bekant med JavaScript eller TypeScript, men är bekant med webbprogramutveckling på serversidan, kommer de förmodligen att kunna leverera en traditionell webbapp snabbare än ett SPA. Om det inte är ett mål att lära sig program-SPA: er, eller om användarupplevelsen som erbjuds av ett SPA krävs, är traditionella webbappar ett mer produktivt val för team som redan är bekanta med att bygga dem.
När du ska välja SPA:er
Följande avsnitt är en mer detaljerad förklaring av när du ska välja en enkelsidig programstil för utveckling för webbappen.
Ditt program måste exponera ett omfattande användargränssnitt med många funktioner
SPA:er har stöd för omfattande funktioner på klientsidan som inte kräver att sidan läses in igen när användarna vidtar åtgärder eller navigerar mellan områden i appen. SPA:er kan läsas in snabbare, hämta data i bakgrunden och enskilda användaråtgärder är mer dynamiska eftersom fullständiga sidinläsningar är sällsynta. SPA:er kan stödja inkrementella uppdateringar och spara delvis slutförda formulär eller dokument utan att användaren behöver klicka på en knapp för att skicka ett formulär. SPA:er kan ha stöd för omfattande beteenden på klientsidan, till exempel dra och släpp, mycket enklare än traditionella program. SPA:er kan utformas för att köras i frånkopplat läge och göra uppdateringar av en modell på klientsidan som så småningom synkroniseras tillbaka till servern när en anslutning har återupprättats. Välj ett SPA-liknande program om appens krav innehåller omfattande funktioner som går utöver vad vanliga HTML-formulär erbjuder.
SpA:er måste ofta implementera funktioner som är inbyggda i traditionella webbappar, till exempel att visa en meningsfull URL i adressfältet som återspeglar den aktuella åtgärden (och låta användare bokmärke eller djuplänk till den här URL:en återgå till den). SPA:er bör också tillåta användare att använda webbläsarens bakåt- och framåtknappar med resultat som inte överraskar dem.
Ditt team är bekant med JavaScript- och/eller TypeScript-utveckling
Att skriva SPA:er kräver kunskaper om programmeringstekniker och bibliotek i JavaScript och/eller TypeScript och på klientsidan. Ditt team bör vara kompetenta att skriva moderna JavaScript med hjälp av ett SPA-ramverk som Angular.
Referenser – SPA-ramverk
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js:https://vuejs.org/
Ditt program måste redan exponera ett API för andra (interna eller offentliga) klienter
Om du redan stöder ett webb-API för användning av andra klienter kan det kräva mindre arbete för att skapa en SPA-implementering som utnyttjar dessa API:er i stället för att återskapa logiken i serverformulär. SPA:er använder webb-API:er i stor utsträckning för att fråga efter och uppdatera data när användarna interagerar med programmet.
När du ska välja Blazor
Följande avsnitt är en mer detaljerad förklaring av när du ska välja Blazor för din webbapp.
Ditt program måste exponera ett omfattande användargränssnitt
Precis som JavaScript-baserade SPA:er Blazor kan program ha stöd för omfattande klientbeteende utan sidbelastningar. Dessa program är mer dynamiska för användare och hämtar endast de data (eller HTML) som krävs för att svara på en viss användarinteraktion. Appar på serversidan Blazor kan konfigureras för att köras som appar på klientsidan Blazor med minimala ändringar när den här funktionen stöds.
Ditt team är mer bekvämt med .NET-utveckling än JavaScript- eller TypeScript-utveckling
Många utvecklare är mer produktiva med .NET och Razor än med språk på klientsidan som JavaScript eller TypeScript. Eftersom serversidan av programmet redan utvecklas med .NET säkerställer användningen Blazor att alla .NET-utvecklare i teamet kan förstå och potentiellt skapa beteendet för programmets klientdel.
Beslutstabell
I följande beslutstabell sammanfattas några av de grundläggande faktorer som du bör tänka på när du väljer mellan ett traditionellt webbprogram, ett SPA eller en Blazor app.
| Faktor | Traditionell webbapp | Enkelsidigt program | Blazor App |
|---|---|---|---|
| Nödvändig teaminlevnad med JavaScript/TypeScript | Minimal | Krävs | Minimal |
| Stöd för webbläsare utan skript | Stöds | Stöds inte | Stöds |
| Minimalt programbeteende på klientsidan | Väl lämpad | Overkill | Livskraftig |
| Omfattande, komplexa krav för användargränssnittet | Begränsad | Väl lämpad | Väl lämpad |
Övriga beaktanden
Traditionella webbappar tenderar att vara enklare och har bättre seo-kriterier (Search Engine Optimization) än SPA-appar. Sökmotorrobotar kan enkelt använda innehåll från traditionella appar, medan stöd för indexering av SPA:er kanske saknas eller är begränsat. Om din app drar nytta av offentlig identifiering av sökmotorer är detta ofta ett viktigt övervägande.
Om du inte har skapat ett hanteringsverktyg för ditt SPA-innehåll kan det dessutom kräva att utvecklare gör ändringar. Traditionella webbappar är ofta enklare för icke-utvecklare att göra ändringar i, eftersom mycket av innehållet helt enkelt är HTML och kanske inte kräver en byggprocess för att förhandsgranska eller ens distribuera. Om icke-utvecklare i din organisation sannolikt behöver underhålla innehållet i appen kan en traditionell webbapp vara ett bättre val.
SPA:er lyser när appen har komplexa interaktiva formulär eller andra funktioner för användarinteraktion. För komplexa appar som kräver autentisering och därför inte är tillgängliga för offentliga sökmotorspindlar är SPA:er ett bra alternativ i många fall.
