Bouw volwaardige webapplicaties met ASP.NET Core Razor Pages.

Home » Python » Bouw volwaardige webapplicaties met ASP.NET Core Razor Pages.

Als je ervaring hebt met Angular en ASP.NET Web API en je begint C# steeds leuker te vinden voor de backend, dan is Razor Pages een ontzettend natuurlijke manier om diezelfde passie naar de frontend te brengen zonder je bestaande JavaScript-kennis te hoeven opgeven. In plaats van halsoverkop over te stappen op een compleet andere UI-stack, kun je binnen het vertrouwde ASP.NET Core-gebied blijven, de Razor-syntaxis gebruiken voor server-side rendering en nog steeds JavaScript toevoegen waar dat zinvol is.

ASP.NET Core Razor Pages is de door Microsoft aanbevolen methode voor het bouwen van moderne webapplicaties op .NET. Het biedt een overzichtelijk, op pagina's gebaseerd model dat is gebouwd bovenop de krachtige ASP.NET Core-pipeline. Het is platformonafhankelijk, werkt naadloos samen met tools zoals Visual Studio, Visual Studio Code en JetBrains Rider, en is schaalbaar van kleine prototypes tot productieklare, databasegestuurde applicaties. In deze handleiding bespreken we hoe Razor Pages-applicaties in de praktijk zijn opgebouwd, hoe Program.cs alles met elkaar verbindt, hoe statische bestanden en configuratie werken en hoe tooling, debuggen en implementatie hierbij een rol spelen.

Wat ASP.NET Core Razor Pages nu eigenlijk is (en hoe het zich verhoudt tot MVC)

Razor Pages is een functie van ASP.NET Core waarmee je webapplicaties kunt bouwen rond pagina's in plaats van controllers. Dit biedt een eenvoudiger denkkader, terwijl het toch hetzelfde onderliggende framework als MVC gebruikt. Technisch gezien draait het op dezelfde routing-, middleware- en hostingstack als controllers en views, maar elke pagina handelt zijn eigen gedrag af in plaats van alles te centraliseren in controllerklassen.

Elke Razor-pagina bestaat doorgaans uit twee bestanden: een .cshtml-bestand voor de opmaak en een .cshtml.cs-bestand voor de C#-logica van de pagina. Het .cshtml-bestand bevat je HTML gemengd met Razor-syntaxis (bijvoorbeeld lussen, voorwaarden en HTML-helpers), terwijl het code-behind-bestand .cshtml.cs handler-methoden zoals OnGet en OnPost, model-eigenschappen en alle logica bevat die nodig is om de pagina weer te geven of te verwerken.

Vóór Razor Pages was het dominante patroon in ASP.NET MVC, waarbij controllers views retourneerden en alle verzoeken via actiemethoden doorstuurden. MVC wordt nog steeds volledig ondersteund en is een beproefd patroon met sterke conventies, maar voor veel scenario's is Razor Pages sneller te begrijpen omdat de code die een pagina laadt en verwerkt zich fysiek naast de markup bevindt in plaats van verborgen in een aparte controller.

Hoewel Razor Pages de focus verlegt van controllers, maakt het nog steeds gebruik van dezelfde Razor-viewengine en ondersteunt het zowel HtmlHelpers als TagHelpers om dynamische HTML te genereren. TagHelpers zijn bijzonder handig: ze breiden normale HTML-tags uit met attributen zoals asp-action, asp-controller or asp-route Zo kun je links en formulieren koppelen aan backend-eindpunten zonder een heleboel handmatige URL's of inline JavaScript te hoeven schrijven.

Voor ontwikkelaars die al bekend zijn met JavaScript en ervaring hebben met SPA-frameworks, biedt Razor Pages een hybride aanpak: server-rendered HTML voor snelle laadtijden en SEO, met JavaScript en front-endbibliotheken die daar bovenop worden geplaatst waar nodig. Je bent niet gebonden aan een specifiek JavaScript-framework en je kunt de backend en frontend in dezelfde oplossing houden, wat de implementatie en het onderhoud vereenvoudigt.

Een Razor Pages-webapp maken en uitvoeren

Wanneer je een nieuw ASP.NET Core Razor Pages-project maakt met Visual Studio, Visual Studio Code of Rider, configureert de sjabloon een minimale maar complete applicatie, inclusief Program.cs, de map Pages, configuratiebestanden en de statische webroot. Je krijgt direct een werkende website die je meteen kunt gebruiken en vervolgens kunt uitbreiden naar iets geavanceerder, zoals een filmcatalogus of een andere datagestuurde applicatie.

Voordat je de app via HTTPS kunt uitvoeren, heeft ASP.NET Core een ontwikkelingscertificaat nodig dat door je besturingssysteem wordt vertrouwd. De eerste keer dat je het project uitvoert, verschijnt er mogelijk een dialoogvenster waarin je wordt gevraagd het certificaat te vertrouwen. Wanneer dat dialoogvenster verschijnt, kunt u kiezen voor Ja Dit geeft aan dat u akkoord gaat met het gebruik van het lokale ontwikkelingscertificaat voor HTTPS-verkeer op uw computer. Dit is vereist voor het correct testen van beveiligde eindpunten zonder browserwaarschuwingen.

Op Windows, macOS of Linux kun je Visual Studio Code starten door op te drukken. Ctrl+F5 U kunt het programma uitvoeren zonder debuggen, of het paneel 'Uitvoeren en debuggen' gebruiken als u de debugger wilt koppelen. De eerste keer dat u VS Code gebruikt, kan het u vragen een debuggertype te selecteren, zoals... C#, .NET 5+ en .NET Core of een specifieke opstartconfiguratie zoals C#: RazorPagesMovie [https] RazorPagesMovie afhankelijk van de .NET-versie en uw werkruimteconfiguratie.

Na het opstarten opent uw standaardbrowser een URL die lijkt op: https://localhost:<port>waarbij de poort willekeurig wordt toegewezen of is gespecificeerd in launchSettings.json, en je de startpagina bekijkt die wordt aangeboden door de Razor Pages-app. In sommige sjablonen ziet u in plaats daarvan het volgende: http://localhost:5001 of een andere haven; het belangrijkste is dat localhost Dit geeft aan dat het uw eigen computer is en geen externe host.

Zodra je klaar bent met testen, kun je de actieve app stoppen vanuit je IDE: in Visual Studio Code ga je naar het menu 'Uitvoeren' en selecteer je 'Foutopsporing stoppen' of druk je op de toets 'Stoppen'. Shift+F5In Visual Studio voor Mac gebruik je hiervoor Debug > Stop Debugging. Dit beëindigt het Kestrel-webserverexemplaar dat voor de sessie was gestart en maakt de poort vrij voor andere processen.

Inzicht in de projectstructuur: mappen en belangrijke bestanden

Echte Razor Pages-applicaties zijn georganiseerd rond een paar belangrijke mappen en configuratiebestanden waarmee je constant zult werken: Pages, wwwroot, appsettings.json en Program.cs (en in oudere versies, Startup.cs). Het is cruciaal om vertrouwd te raken met deze onderdelen, omdat vrijwel elke tutorial, voorbeeld of productieproject dezelfde conventies hanteert.

De map 'Pages' vormt het hart van een Razor Pages-project en bevat alle .cshtml-pagina's en hun .cshtml.cs-codebestanden, samen met gedeelde lay-out- en partial views. Elk paginapaar (bijvoorbeeld Index.cshtml en Index.cshtml.cs) vertegenwoordigt een aanroepbaar eindpunt in uw app, en speciale bestanden die beginnen met een underscore, zoals _Layout.cshtmldefinieer inhoud die op meerdere pagina's wordt hergebruikt.

Het lay-outbestand, meestal genaamd _Layout.cshtmldefinieert de vormgeving van uw site, zoals de bovenste navigatiebalk, de voettekst en de copyrightvermelding, en biedt een plek om de inhoud van elke afzonderlijke pagina weer te geven. Wanneer je de lay-out wijzigt, heeft dit direct invloed op het uiterlijk van alle Razor Pages die ervan gebruikmaken. Daarom is dit dé plek om menu's, huisstijl en gedeelde scripts of stijlen te bewerken.

De wwwroot-map is de aangewezen webroot waar statische bestanden worden opgeslagen, waaronder CSS, JavaScript, afbeeldingen en gewone HTML-bestanden die direct door de webserver kunnen worden aangeboden. Alles wat onder wwwroot wordt geplaatst, is toegankelijk voor de browser (afhankelijk van uw configuratie voor statische bestanden), waardoor het de juiste plek is voor site-stylesheets, client-side libraries en afbeeldingen waarnaar in uw markup wordt verwezen.

De configuratie voor de app wordt doorgaans opgeslagen in appsettings.json (en omgevingsspecifieke varianten zoals appsettings.Development.json), die instellingen bevatten zoals verbindingsreeksen en functievlaggen. Het configuratiesysteem van ASP.NET Core laadt deze bestanden en combineert ze met omgevingsvariabelen en andere providers, waardoor het eenvoudig is om secties te koppelen aan sterk getypeerde optieklassen in uw code.

Program.cs en de ASP.NET Core-pipeline

Het bestand Program.cs bevat het startpunt voor uw Razor Pages-app en definieert hoe de webhost, services en middleware-pipeline worden geconfigureerd voordat het eerste verzoek uw site bereikt. In moderne ASP.NET Core-versies gebruikt Program.cs een gestroomlijnd "minimaal hosting"-model met een top-level instructie die een WebApplicationBuilder en bouwt en configureert vervolgens de WebApplication aanleg.

Het typische patroon in Program.cs begint met var builder = WebApplication.CreateBuilder(args); die een host instelt met standaardinstellingen en vervolgens aanroept builder.Services.AddRazorPages(); Razor Pages registreren bij de dependency injection-container. Na het configureren van de services, var app = builder.Build(); Hiermee wordt het applicatieobject aangemaakt dat je vervolgens koppelt aan middleware en eindpunten.

Foutafhandeling en beveiligingsgedrag zijn sterk afhankelijk van de omgeving, dus je ziet meestal een omgevingscontrole zoals deze. if (!app.Environment.IsDevelopment()) om functies van productiekwaliteit mogelijk te maken. Binnen die omstandigheden vindt u normaal gesproken het volgende: app.UseExceptionHandler("/Error"); die onafgehandelde fouten doorstuurt naar een speciale foutpagina, en app.UseHsts(); Dit activeert HTTP Strict Transport Security (HSTS) om browsers te instrueren altijd HTTPS te gebruiken voor uw domein.

De middleware-pipeline wordt vervolgens samengesteld met aanroepen zoals app.UseHttpsRedirection();, app.UseStaticFiles(); or app.MapStaticAssets();, app.UseRouting(); en optioneel app.UseAuthorization(); gevolgd door eindpunttoewijzingen. HTTPS-omleiding dwingt onveilige HTTP-verzoeken om te worden geüpgraded naar HTTPS, middleware voor statische bestanden (of de nieuwere statische assetmapping in .NET 9) maakt het mogelijk om resources rechtstreeks vanuit wwwroot aan te bieden, en routing bepaalt welk eindpunt elke binnenkomende URL afhandelt.

Tot slot zijn Razor Pages aangesloten op de routering met app.MapRazorPages(); optioneel gekoppeld aan .WithStaticAssets(); In nieuwere sjablonen is optimalisatie van statische bestanden geïntegreerd, en de applicatie wordt gestart met app.Run();. Op dat moment luistert de app op de geconfigureerde poorten en is de Kestrel-server klaar om echte verzoeken af ​​te handelen, zowel lokaal tijdens de ontwikkeling als op een productiehost zoals IIS, Azure App Service of Docker.

Razor Pages, modellen en weergavemodellen in echte toepassingen

Achter elke serieuze Razor Pages-app schuilt een set domeinmodellen en weergavemodellen die uw gegevens en de manier waarop deze worden weergegeven, representeren, of u nu een filmcatalogus, een blog of een bedrijfsdashboard beheert. Modellen komen doorgaans nauw overeen met database-entiteiten, terwijl view-modellen kunnen worden afgestemd op een specifiek scherm of gebruikersstroom, waarbij meerdere modellen of vooraf opgemaakte waarden worden gecombineerd voor een eenvoudigere weergave.

Een veelgebruikte ontwikkelingsworkflow begint met eenvoudige C#-klassen die velden en methodesignaturen als placeholders gebruiken, en ontwikkelt deze geleidelijk tot volwaardige modellen met ingekapselde eigenschappen, validatiekenmerken en logica. Tools zoals JetBrains Rider maken die evolutie soepeler met intentieacties die automatisch velden omzetten naar eigenschappen, afgeleide typen creëren voor overervingshiërarchieën en andere refactoring toepassen naarmate u uw objectmodel verfijnt.

Overerving en interfaces helpen een coherente structuur voor uw modellen af ​​te dwingen, waardoor ze aansluiten bij de daadwerkelijke bedrijfsregels en polymorfisme mogelijk wordt, waarbij bepaalde gedragingen worden gedeeld maar de implementaties verschillen. Je zou bijvoorbeeld een basis kunnen hebben. ContentItem type met afgeleide Movie, Series en Documentary klassen, elk met subtiele verschillen, maar met een gemeenschappelijk contract dat in je hele app wordt gebruikt.

Zodra uw modellen gereed zijn, kunnen Razor Pages of MVC-weergaven handmatig of met behulp van scaffolding-tools worden gemaakt. Deze tools genereren pagina's voor het weergeven, aanmaken, bewerken en verwijderen van entiteiten. Scaffolding versnelt de vroege ontwikkelingsfase aanzienlijk en zorgt ervoor dat routing, modelbinding en validatie correct zijn geconfigureerd, die je vervolgens kunt aanpassen met je eigen markup en styling.

De Razor-syntaxis die in .cshtml-bestanden wordt gebruikt, combineert naadloos met sterk getypeerde modellen en viewmodellen. Hierdoor kunt u gegevens weergeven, lussen en voorwaarden uitvoeren en links en formulieren genereren met behulp van HtmlHelpers of TagHelpers, zonder dat de compileerbaarheid in gevaar komt. Deze combinatie van C# en markup zorgt ervoor dat veel logica aan de serverzijde blijft, maar levert toch schone HTML in de browser op die goed samenwerkt met CSS en JavaScript.

Werken met Razor-syntaxis, TagHelpers en navigatie in Rider

Razor-syntaxis is een dunne laag bovenop HTML die in werking treedt wanneer de @ Het symbool verschijnt, waardoor het eenvoudig is om C#-expressies, -instructies of hulpfunctieaanroepen rechtstreeks in uw markup in te sluiten. Je kunt door lijsten met items lopen, elementen tonen of verbergen op basis van voorwaarden, of waarden en opgemaakte datums weergeven zonder een aparte sjabloontaal te schrijven of overal JavaScript te gebruiken.

TagHelpers voelen aan als een natuurlijke uitbreiding van HTML, waar speciale attributen die beginnen met asp- Het gedrag of de uitvoer van elementen aanpassen, vaak ter vervanging van oudere HtmlHelper-methoden en de noodzaak voor inline script-lijm wegnemen. Voorbeelden zijn asp-action en asp-controller om ankertags en formulieren naar specifieke acties te routeren, of attributen zoals asp-route-id Om parameters op een nette manier in URL's door te geven.

IDE-ondersteuning is erg belangrijk wanneer je diep in HTML zit, en Rider biedt handige functies zoals breadcrumbs onderaan de editor om je huidige positie in de documentstructuur weer te geven. De breadcrumbs kunnen worden aangepast onder Voorkeuren of Opties in het Editor-gedeelte, en ze maken het navigeren door lange Razor-bestanden met geneste tags een stuk minder omslachtig.

In MVC-projecten begrijpt Rider ook de conventies die controllers, acties en weergaven met elkaar verbinden, zodat je bij het hoveren over actieresultaten de mogelijke weergavepaden kunt zien. Ctrl + klikken (of Cmd-klik (op macOS) springt direct naar het bijbehorende .cshtml-bestand. Snelkoppelingen zoals Ctrl + B or Cmd-B Bied een snelle manier om door je codebase te navigeren zonder te hoeven zoeken in oplossingsverkenners.

Naast de specifieke tools voor Razor, bevat Rider een breed scala aan intenties en snelle oplossingen voor HTML, CSS en JavaScript waarmee je schone, goed gestructureerde client-side code kunt schrijven binnen dezelfde IDE als je C#-backend. Deze nauwe integratie kan veel contextwisselingen besparen bij het bouwen van complexe, interactieve gebruikersinterfaces die nog steeds afhankelijk zijn van server-gerenderde Razor-weergaven of -pagina's.

Foutopsporing van Razor Pages en ASP.NET Core-apps

Debuggen is een dagelijkse bezigheid in webontwikkeling, en ASP.NET Core-apps die Razor Pages gebruiken vormen daarop geen uitzondering. Daarom is goede debugondersteuning in je IDE essentieel. Zowel Visual Studio als Rider bieden interactieve debuggers waarmee je je kunt koppelen aan je Kestrel-proces, C#-code kunt doorlopen, variabelen kunt inspecteren en expressies kunt evalueren terwijl de app draait.

De Rider-debugger op Windows ondersteunt 'Bewerken en doorgaan', waarmee u code kunt aanpassen terwijl de app is gepauzeerd bij een breekpunt en de wijzigingen kunt toepassen zonder de hele debugsessie opnieuw te starten. De mogelijkheid om kleine fouten te herstellen of te experimenteren tijdens het debuggen versnelt het oplossen van problemen aanzienlijk, vooral bij grote projecten met aanzienlijke opstarttijden.

De standaardpagina voor ontwikkelaarsfouten in ASP.NET Core wordt automatisch ingeschakeld wanneer de omgeving is ingesteld op Ontwikkeling. Deze pagina biedt een gedetailleerde stacktrace, informatie over het verzoek en diagnostische gegevens wanneer er onafgehandelde uitzonderingen optreden. Deze weergave is uiterst nuttig tijdens lokaal debuggen, maar gevaarlijk in een productieomgeving omdat deze interne details over uw app en omgeving kan lekken.

Om gevoelige informatie te beschermen, schakelen productie- en testomgevingen doorgaans de pagina voor ontwikkelaarsuitzonderingen uit en gebruiken in plaats daarvan de geconfigureerde route voor uitzonderingsafhandeling, vaak /Error, om een ​​gebruiksvriendelijk foutscherm weer te geven terwijl de werkelijke gegevens aan de serverzijde worden vastgelegd. Dit gedrag wordt in Program.cs gecontroleerd via de omgevingscontrole en aanroepen naar UseExceptionHandler en UseHsts.

Als de zaken echt mislopen en de handleidingen niet aansluiten bij jouw werkwijze, is het vaak nuttig om je project te vergelijken met een bekend, goed voorbeeld van Microsoft of andere gezaghebbende bronnen. Veel officiële Razor Pages-tutorials publiceren een compleet voorbeeldproject dat je kunt bekijken of downloaden om te vergelijken met je eigen code en zo ontbrekende configuratie, typefouten of verkeerd geplaatste bestanden op te sporen.

Het publiceren en implementeren van echte ASP.NET Core Razor-apps

Het lanceren van je Razor Pages-app is waar alle eerdere structuur en configuratie hun vruchten afwerpen, omdat ASP.NET Core verschillende implementatieopties ondersteunt die passen bij verschillende hostingomgevingen en workflows. Of je nu de voorkeur geeft aan IIS op Windows, Linux-containers in Docker of een beheerd platform zoals Azure App Service, het publicatieproces kan worden aangestuurd door MSBuild en worden geïntegreerd in je CI/CD-pipelines.

Zowel Visual Studio als Rider bieden publicatieprofielen waarmee u uw applicatie kunt verpakken en implementeren op IIS met behulp van Web Deploy (MSDeploy), kopiëren naar een lokale of netwerkmap, of rechtstreeks naar een externe server kunt pushen via FTP, FTPS of SFTP. Door een publicatieprofiel aan te maken, worden uw implementatie-instellingen vastgelegd, zodat toekomstige publicaties net zo eenvoudig zijn als het selecteren van het profiel en het klikken op een knop of het uitvoeren van een opdracht.

Voor cloudscenario's is Azure App Service een populaire keuze, en IDE's integreren Azure-tools om webapps rechtstreeks vanuit je project te maken en te publiceren, waarbij ze wederom gebruikmaken van MSBuild en MSDeploy. Deze aanpak zorgt ervoor dat het bouw- en implementatieproces consistent blijft tussen lokale en cloudomgevingen en kan worden geautomatiseerd in Azure DevOps, GitHub Actions of andere CI-systemen.

Docker is een andere uitstekende optie voor ASP.NET Core, waarmee je je Razor Pages-app in een container kunt plaatsen, zodat deze betrouwbaar kan worden uitgevoerd in elke omgeving die containers ondersteunt. Rider en Visual Studio kunnen je helpen bij het genereren van Dockerfiles en docker-compose-configuraties, waardoor een workflow mogelijk wordt waarin je je app ontwikkelt, debugt en implementeert in containers, zowel lokaal als in orchestrators zoals Kubernetes.

Ongeacht het doelplatform compileert de publicatiestap uw C#-code, bundelt Razor-weergaven, kopieert statische bestanden en kan, afhankelijk van de instellingen, ook een zelfstandige runtime genereren, zodat de hostmachine geen gedeelde .NET-installatie nodig heeft. Door deze bundeling wordt uw ontwikkelingsproject een implementeerbaar product dat direct door echte gebruikers kan worden gebruikt.

Door al deze onderdelen samen te voegen – van ontwikkelingscertificaten en Program.cs, via Pages en wwwroot, tot debuggen en publiceren – biedt Razor Pages een pragmatische manier om realistische ASP.NET Core-webapplicaties te bouwen die onderhoudbaar, performant en gebruiksvriendelijk zijn voor ontwikkelaars die al graag met C# werken en nog niet klaar zijn om volledig over te stappen op een single-page framework voor elke situatie.