Bygg ekte webapplikasjoner med ASP.NET Core Razor Pages

Home » Python » Bygg ekte webapplikasjoner med ASP.NET Core Razor Pages

Hvis du kommer fra Angular pluss ASP.NET Web API og begynner å like C# på backend, er Razor Pages en utrolig naturlig måte å bringe den gleden til frontend uten å gi opp dine eksisterende JavaScript-kunnskaper. I stedet for å hoppe hodestups inn i en helt annen UI-stabel, kan du holde deg i kjent ASP.NET Core-territorium, bruke Razor-syntaksen for serverside-rendering, og fortsatt strø JavaScript der det gir mening.

ASP.NET Core Razor Pages er Microsofts anbefalte tilnærming for å bygge moderne webapper på .NET, og tilbyr en ren sidebasert modell som ligger oppå den kraftige ASP.NET Core-pipelinen. Den er plattformuavhengig, fungerer sømløst med verktøy som Visual Studio, Visual Studio Code og JetBrains Rider, og skalerer fra små prototyper til databasebaserte applikasjoner i produksjonsklassen. I denne veiledningen skal vi gå gjennom hvordan virkelige Razor Pages-apper er strukturert, hvordan Program.cs kobler alt sammen, hvordan statiske filer og konfigurasjon fungerer, og hvordan verktøy, feilsøking og distribusjon kommer inn i bildet.

Hva ASP.NET Core Razor Pages egentlig er (og hvordan det sammenlignes med MVC)

Razor Pages er en funksjon i ASP.NET Core som lar deg bygge webapper rundt sider i stedet for kontrollere, og tilbyr en enklere mental modell samtidig som du bruker det samme underliggende rammeverket som MVC. Under panseret kjører den på samme ruting, mellomvare og hostingstabel som kontrollere og visninger, men hver side håndterer sin egen oppførsel i stedet for å sentralisere alt i kontrollerklasser.

Hver Razor-side er vanligvis representert av et par filer: en .cshtml-fil for markup og en .cshtml.cs-fil for sidens C#-logikk. .cshtml-filen inneholder HTML-koden din blandet med Razor-syntaks (for eksempel løkker, betingelser og HTML-hjelpere), mens koden bak .cshtml.cs-filen inneholder håndteringsmetoder som OnGet, OnPost, modellegenskaper og all logikk som trengs for å gjengi eller behandle siden.

Før Razor Pages var det dominerende mønsteret i ASP.NET MVC, der kontrollere returnerte visninger og rutet alle forespørsler gjennom handlingsmetoder. MVC støttes fortsatt fullt ut og er et mønster som er testet i kamp med sterke konvensjoner, men for mange scenarier er Razor Pages raskere å resonnere rundt fordi koden som laster inn og behandler en side er fysisk ved siden av markupen i stedet for begravd i en separat kontroller.

Selv om Razor Pages flytter fokuset bort fra kontrollere, bruker den fortsatt den samme Razor-visningsmotoren og støtter både HtmlHelpers og TagHelpers for å generere dynamisk HTML. TagHelpers er spesielt nyttige: de utvider vanlige HTML-tagger med attributter som asp-action, asp-controller or asp-route slik at du kan koble lenker og skjemaer til backend-endepunkter uten å skrive en rekke manuelle URL-er eller innebygd JavaScript.

For utviklere som allerede kjenner JavaScript og har jobbet med SPA-rammeverk, tilbyr Razor Pages en hybrid tilnærming: server-rendered HTML for rask første innlasting og SEO, med JavaScript og front-end-biblioteker lagt oppå der det er nødvendig. Du er ikke låst til eller mot noe bestemt JS-rammeverk, og du kan beholde backend og frontend i samme løsning, noe som forenkler utrulling og vedlikehold.

Opprette og kjøre en Razor Pages-nettapp

Når du oppretter et nytt ASP.NET Core Razor Pages-prosjekt ved hjelp av Visual Studio, Visual Studio Code eller Rider, kobler malen til et minimalt, men komplett program, inkludert Program.cs, Pages-mappen, konfigurasjonsfiler og den statiske webroten. Rett ut av esken får du et fungerende nettsted som du kan kjøre umiddelbart og deretter utvikle til noe mer sofistikert, som en filmkatalog eller en annen datadrevet app.

Før appen kjøres på HTTPS, må ASP.NET Core bruke et utviklingssertifikat som operativsystemet ditt stoler på, og første gang du kjører prosjektet, kan det hende du ser en dialogboks som ber deg om å stole på det. Når dialogboksen vises, velger du Ja indikerer at du er ok med at det lokale utviklingssertifikatet brukes til HTTPS-trafikk på maskinen din, noe som er nødvendig for riktig testing av sikre endepunkter uten nettleseradvarsler.

På Windows, macOS eller Linux lar Visual Studio Code deg starte appen ved å trykke på Ctrl+F5 for å kjøre uten feilsøking, eller bruke Kjør og feilsøk-panelet hvis du vil koble til feilsøkingsprogrammet. Første gang kan VS Code be deg om å velge en feilsøkingstype, for eksempel C#, .NET 5+ og .NET Core eller en spesifikk oppstartskonfigurasjon som C#: RazorPagesMovie [https] RazorPagesMovie avhengig av .NET-versjonen og arbeidsområdekonfigurasjonen din.

Etter oppstart åpnes standardnettleseren din på en URL som ligner på https://localhost:<port>, der porten er tilfeldig tildelt eller spesifisert i launchSettings.json, og du ser på hjemmesiden som betjenes av Razor Pages-appen. I noen maler vil du i stedet se http://localhost:5001 eller en annen port; det viktigste er at localhost indikerer at det er din egen maskin og ikke en ekstern vert.

Når du er ferdig med testingen, kan du stoppe den kjørende appen fra IDE-en din: i Visual Studio Code bruker du Kjør-menyen og velger Stopp feilsøking, eller trykk på Skift+F5, mens du i Visual Studio for Mac bruker Feilsøking > Stopp feilsøking. Dette avslutter Kestrel-webserverforekomsten som ble startet for økten og frigjør porten for andre kjøringer.

Forstå prosjektstrukturen: mapper og nøkkelfiler

Ekte Razor Pages-applikasjoner er organisert rundt noen få viktige mapper og konfigurasjonsfiler som du vil jobbe med hele tiden: Pages, wwwroot, appsettings.json og Program.cs (og i eldre versjoner, Startup.cs). Det er avgjørende å bli komfortabel med å navigere i disse delene, fordi så godt som alle veiledninger, eksempler eller produksjonsprosjekter bruker de samme konvensjonene.

Pages-mappen er kjernen i et Razor Pages-prosjekt, og inneholder alle .cshtml-sidene og deres .cshtml.cs-kodebakgrunnsfiler, sammen med delt layout og delvise visninger. Hvert sidepar (for eksempel Index.cshtml og Index.cshtml.cs) representerer et kallbart endepunkt i appen din, og spesielle filer som starter med et understrek, for eksempel _Layout.cshtml, definerer innhold som brukes om igjen på tvers av mange sider.

Layoutfilen, vanligvis kalt _Layout.cshtml, definerer krominnholdet på nettstedet ditt, som for eksempel den øverste navigasjonslinjen, bunnteksten og opphavsrettserklæringen, og gir et sted å gjengi brødteksten på hver enkelt side. Når du endrer layouten, påvirker du umiddelbart utseendet og følelsen til alle Razor Pages som bruker den, så det er det perfekte stedet for å redigere menyer, merkevarebygging og delte skript eller stiler.

wwwroot-mappen er den angitte webroten der statiske ressurser finnes, inkludert CSS, JavaScript, bilder og vanlige HTML-filer som kan serveres direkte av webserveren. Alt som er plassert under wwwroot kan nås av nettleseren (avhengig av konfigurasjonen av den statiske filen), noe som gjør den til det rette hjemmet for stilark for nettsteder, klientsidebiblioteker og bilder som det refereres til i markupen din.

Konfigurasjonen for appen lagres vanligvis i appsettings.json (og miljøspesifikke varianter som appsettings.Development.json), som inneholder innstillinger som tilkoblingsstrenger og funksjonsflagg. ASP.NET Cores konfigurasjonssystem laster inn disse filene og slår dem sammen med miljøvariabler og andre leverandører, noe som gjør det enkelt å binde seksjoner til sterkt typede opsjonsklasser i koden din.

Program.cs og ASP.NET Core-pipelinen

Program.cs-filen inneholder inngangspunktet for Razor Pages-appen din og definerer hvordan webhotellet, tjenestene og mellomvare-pipelinen konfigureres før den første forespørselen treffer nettstedet ditt. I moderne ASP.NET Core-versjoner bruker Program.cs en strømlinjeformet «minimal hosting»-modell med en toppnivåsetning som oppretter en WebApplicationBuilder og bygger og konfigurerer deretter WebApplication forekomst.

Det typiske mønsteret i Program.cs starter med var builder = WebApplication.CreateBuilder(args); som setter opp en vert med vanlige standardinnstillinger, og deretter kaller builder.Services.AddRazorPages(); for å registrere Razor Pages med avhengighetsinjeksjonsbeholderen. Etter å ha konfigurert tjenester, var app = builder.Build(); oppretter applikasjonsobjektet som du deretter kobler til mellomvare og endepunkter.

Feilhåndtering og sikkerhetsatferd avhenger i stor grad av miljøet, så du ser vanligvis en miljøsjekk som if (!app.Environment.IsDevelopment()) for å aktivere funksjoner i produksjonsklassen. Innenfor den tilstanden finner du vanligvis app.UseExceptionHandler("/Error"); som sender ubehandlede feil til en dedikert feilside, og app.UseHsts(); som aktiverer HTTP Strict Transport Security (HSTS) for å instruere nettlesere til alltid å bruke HTTPS for domenet ditt.

Mellomvare-pipelinen settes deretter sammen med kall som app.UseHttpsRedirection();, app.UseStaticFiles(); or app.MapStaticAssets();, app.UseRouting(); og valgfritt app.UseAuthorization(); etterfulgt av endepunkttilordninger. HTTPS-omdirigering tvinger usikre HTTP-forespørsler til å bli oppgradert til HTTPS, statisk filmellomvare (eller den nyere statiske ressurstilordningen i .NET 9) tillater direkte servering av ressurser fra wwwroot, og ruting bestemmer hvilket endepunkt som håndterer hver innkommende URL.

Til slutt er Razor Pages koblet til ruting med app.MapRazorPages(); eventuelt lenket med .WithStaticAssets(); i nyere maler for å integrere statisk ressursoptimalisering, og applikasjonen startes med app.Run();. På det tidspunktet lytter appen på konfigurerte porter, og Kestrel-serveren er klar til å håndtere reelle forespørsler, enten lokalt under utvikling eller på en produksjonsvert som IIS, Azure App Service eller Docker.

Razor-sider, modeller og visningsmodeller i virkelige applikasjoner

Bak hver ikke-trivielle Razor Pages-app ligger et sett med domenemodeller og visningsmodeller som representerer dataene dine og hvordan de vises, enten du administrerer en filmkatalog, en blogg eller et forretningsdashbord. Modeller tilordnes vanligvis tett til databaseenheter, mens visningsmodeller kan skreddersys til én spesifikk skjerm eller brukerflyt, og kombinere flere modeller eller forhåndsformaterte verdier for enklere gjengivelse.

En vanlig utviklingsarbeidsflyt er å starte med enkle C#-klasser som bruker felt og metodesignaturer som stubber, og gradvis utvikle dem til riktige modeller med innkapslede egenskaper, valideringsattributter og logikk. Verktøy som JetBrains Rider gjør den utviklingen smidigere med intensjonshandlinger som automatisk konverterer felt til egenskaper, oppretter avledede typer for arvshierarkier og bruker andre refaktoreringer når du forbedrer objektmodellen.

Arv og grensesnitt bidrar til å håndheve en sammenhengende struktur for modellene dine, justere dem med reelle forretningsregler og muliggjøre polymorfisme der visse atferder deles, men implementeringene er forskjellige. For eksempel kan du ha en base ContentItem type med avledet Movie, Series og Documentary klasser, hver med subtile forskjeller, men en felles kontrakt som brukes i hele appen din.

Når modellene dine er på plass, kan Razor Pages eller MVC-visninger opprettes enten manuelt eller via stillasverktøy som genererer sider for oppføring, oppretting, redigering og sletting av enheter. Stillas fremskynder tidlig utvikling betraktelig og sikrer at ruting, modellbinding og validering er riktig koblet, noe du deretter kan tilpasse med din egen markup og styling.

Razor-syntaksen som brukes i .cshtml-filer kombineres problemfritt med modeller med sterkt typede mønstre og viser modeller, slik at du kan vise data, kjøre løkker og betingelser, og generere lenker og skjemaer ved hjelp av HtmlHelpers eller TagHelpers uten å miste sikkerheten ved kompilering. Denne blandingen av C# og markup beholder mye logikk på serversiden, men gir fortsatt ren HTML i nettleseren som fungerer fint sammen med CSS og JavaScript.

Arbeid med Razor-syntaks, TagHelpers og navigasjon i Rider

Razor-syntaks er et tynt lag over HTML som aktiveres når @ Symbolet vises, noe som gjør det enkelt å legge inn C#-uttrykk, -setninger eller -hjelpekall direkte i markupen din. Du kan gå gjennom lister over elementer, vise eller skjule elementer basert på betingelser, eller vise verdier og formaterte datoer uten å skrive et separat malspråk eller strø JavaScript overalt.

TagHelpers føles som en naturlig forlengelse av HTML der spesielle attributter som starter med asp- endre oppførselen eller utdataene til elementer, og erstatter ofte eldre HtmlHelper-metoder og fjerner behovet for innebygd skriptlim. Eksempler på dette er asp-action og asp-controller å rute ankerkoder og skjemaer til bestemte handlinger, eller rute attributter som asp-route-id å sende parametere rent i URL-er.

IDE-støtte er svært viktig når du er godt kjent med HTML, og Rider tilbyr nyttige funksjoner som brødsmuler nederst i editoren for å vise din nåværende plassering i dokumentets struktur. Brødsmuler kan tilpasses under Innstillinger eller Alternativer i redigeringsdelen, og de gjør det mye mindre smertefullt å navigere i lange Razor-filer med nestede tagger.

I MVC-prosjekter forstår Rider også konvensjonene som kobler sammen kontrollere, handlinger og visninger, så å holde musepekeren over handlingsresultatene kan vise deg mulige visningsbaner og Ctrl + Klikk (eller Cmd-klikk på macOS) hopper direkte til den tilsvarende .cshtml-filen. Snarveier som Ctrl + B or Cmd-B gi en rask måte å navigere gjennom kodebasen din uten å måtte lete gjennom løsningsutforskere.

Utover Razor-spesifikke verktøy, inkluderer Rider et bredt sett med intensjoner og hurtigreparasjoner for HTML, CSS og JavaScript som hjelper deg med å skrive ren, velstrukturert klientsidekode i samme IDE som C#-backend. Denne tette integrasjonen kan spare mange kontekstbytter når man bygger komplekse, interaktive brukergrensesnitt som fortsatt er avhengige av server-gjengitte Razor-visninger eller -sider.

Feilsøking av Razor Pages og ASP.NET Core-apper

Feilsøking er en daglig aktivitet i webutvikling, og ASP.NET Core-apper som kjører Razor Pages er intet unntak, så det er viktig å ha sterk feilsøkingsstøtte i IDE-en din. Både Visual Studio og Rider tilbyr interaktive feilsøkingsprogrammer som kan kobles til Kestrel-prosessen din, gå gjennom C#-kode, inspisere variabler og evaluere uttrykk mens appen kjører.

Riders feilsøkingsprogram på Windows støtter Rediger og Fortsett, som lar deg justere kode mens appen er satt på pause ved et avbruddspunkt og bruke endringene uten å starte hele feilsøkingsøkten på nytt. Den muligheten til å fikse små feil eller eksperimentere under en feilsøkingskjøring fremskynder feilsøkingen betraktelig, spesielt i store prosjekter med ikke-trivielle oppstartstider.

Standardsiden for utviklerunntak i ASP.NET Core aktiveres automatisk når miljøet er satt til Utvikling, og gir deg detaljert stakksporing, forespørselsinformasjon og diagnostikk når det oppstår ubehandlede unntak. Denne visningen er ekstremt nyttig under lokal feilsøking, men farlig i produksjon fordi den kan lekke interne detaljer om appen og miljøet ditt.

For å beskytte sensitiv informasjon deaktiverer produksjons- og testmiljøer vanligvis utviklerens unntaksside og bruker i stedet den konfigurerte unntakshåndtererruten, ofte /Error, for å vise et brukervennlig feilskjermbilde mens de faktiske detaljene logges på serversiden. Denne oppførselen kontrolleres i Program.cs via miljøkontrollen og kall til UseExceptionHandler og UseHsts.

Når ting virkelig går av sporet og veiledningene ikke samsvarer med oppførselen din, er det ofte nyttig å sammenligne prosjektet ditt med et kjent godt eksempel levert av Microsoft eller andre autoritative kilder. Mange offisielle Razor Pages-veiledninger publiserer et ferdig eksempelprosjekt som du kan se eller laste ned for å sammenligne det med din egen kode og finne manglende konfigurasjon, skrivefeil eller feilplasserte filer.

Publisering og distribusjon av ekte ASP.NET Core Razor-apper

Det er når du leverer Razor Pages-appen din at all den tidligere strukturen og konfigurasjonen lønner seg, fordi ASP.NET Core støtter flere distribusjonsalternativer som passer til forskjellige hostingmiljøer og arbeidsflyter. Enten du foretrekker IIS på Windows, Linux-containere i Docker eller en administrert plattform som Azure App Service, kan publiseringsprosessen drives av MSBuild og integreres i CI/CD-pipelinene dine.

Både Visual Studio og Rider tilbyr publiseringsprofiler som kan pakke applikasjonen din og distribuere den til IIS ved hjelp av Web Deploy (MSDeploy), kopiere den til en lokal mappe eller nettverksmappe, eller sende den direkte til en ekstern server via FTP, FTPS eller SFTP. Når du oppretter en publiseringsprofil, kodes distribusjonsinnstillingene dine, slik at fremtidige publiseringer er like enkle som å velge profilen og klikke på en knapp eller kjøre en kommando.

For skyscenarioer er Azure App Service et populært mål, og IDE-er integrerer Azure-verktøy for å opprette og publisere webapper rett fra prosjektet ditt, igjen ved å dra nytte av MSBuild og MSDeploy under panseret. Denne tilnærmingen sørger for at bygging og distribusjon er konsistent mellom lokale og skybaserte miljøer, og kan automatiseres i Azure DevOps, GitHub Actions eller andre CI-systemer.

Docker er et annet førsteklasses alternativ for ASP.NET Core, som lar deg containerisere Razor Pages-appen din slik at den kan kjøres forutsigbart i ethvert miljø som støtter containere. Rider og Visual Studio kan hjelpe deg med å generere Dockerfiles og docker-compose-konfigurasjoner, noe som muliggjør en arbeidsflyt der du utvikler, feilsøker og distribuerer appen din i containere, enten lokalt eller i orkestratorer som Kubernetes.

Uansett mål kompilerer publiseringstrinnet C#-koden din, pakker Razor-visninger, kopierer statiske ressurser og, avhengig av innstillinger, kan det også generere en selvstendig kjøretid slik at vertsmaskinen ikke trenger en delt .NET-installasjon. Denne bundlingen er det som gjør utviklingsprosjektet ditt til en distribuerbar artefakt klar til bruk av virkelige brukere.

Ved å sette alle disse delene sammen – fra utviklingssertifikater og Program.cs, via Pages og wwwroot, til feilsøking og publisering – tilbyr Razor Pages en pragmatisk måte å bygge ASP.NET Core-webapplikasjoner i den virkelige verden som er vedlikeholdbare, effektive og komfortable for utviklere som allerede liker å jobbe i C# og ikke er klare til å satse fullt ut på et rammeverk med én side for enhver situasjon.