- Razor Pages oferă un model centrat pe pagină bazat pe ASP.NET Core, partajând aceeași rutare puternică, middleware și motor de vizualizare Razor ca MVC.
- Proiectele reale se concentrează în jurul folderului Pages, wwwroot, appsettings.json și Program.cs, unde sunt configurate serviciile, middleware-ul și gestionarea erorilor.
- Instrumente precum Visual Studio, Rider și VS Code simplifică dezvoltarea, depanarea, navigarea și refactorizarea modelelor, vizualizărilor și sintaxei Razor.
- ASP.NET Core simplifică publicarea aplicațiilor Razor pe IIS, Azure, servere personalizate sau Docker, permițând implementări scalabile și repetabile.
Dacă vii de la Angular plus ASP.NET Web API și începi să te bucuri de C# în backend, Razor Pages este o modalitate incredibil de naturală de a aduce această bucurie în frontend fără a abandona cunoștințele tale existente de JavaScript. În loc să te arunci cu capul înainte într-o stivă de interfață utilizator complet diferită, poți rămâne în teritoriul familiar ASP.NET Core, poți utiliza sintaxa Razor pentru randarea pe server și totuși să adaugi JavaScript oriunde are sens.
ASP.NET Core Razor Pages este abordarea recomandată de Microsoft pentru construirea de aplicații web moderne pe .NET, oferind un model curat bazat pe pagini, care se bazează pe puternicul canal ASP.NET Core. Este multiplatformă, funcționează perfect cu instrumente precum Visual Studio, Visual Studio Code și JetBrains Rider și se scalează de la prototipuri minuscule la aplicații de producție, bazate pe baze de date. În acest ghid, vom analiza modul în care sunt structurate aplicațiile Razor Pages din lumea reală, cum Program.cs conectează totul împreună, cum funcționează fișierele statice și configurația și cum intră în joc instrumentele, depanarea și implementarea.
Ce este de fapt ASP.NET Core Razor Pages (și cum se compară cu MVC)
Razor Pages este o caracteristică a ASP.NET Core care vă permite să construiți aplicații web în jurul paginilor în loc de controlere, oferind un model mental mai simplu, utilizând în același timp același framework de bază ca MVC. Sub capotă, rulează pe aceeași stivă de rutare, middleware și găzduire ca și controlerele și vizualizările, dar fiecare pagină își gestionează propriul comportament în loc să centralizeze totul în clase de controlere.
Fiecare pagină Razor este reprezentată de obicei de o pereche de fișiere: un fișier .cshtml pentru markup și un fișier .cshtml.cs pentru logica C# a paginii. Fișierul .cshtml conține codul HTML combinat cu sintaxa Razor (de exemplu, bucle, condiții și instrumente HTML helper), în timp ce fișierul .cshtml.cs din spatele codului conține metode de gestionare precum OnGet, OnPost, proprietăți ale modelului și orice logică necesară pentru a reda sau procesa pagina.
Înainte de Razor Pages, modelul dominant în ASP.NET era MVC, unde controlerele returnau vizualizări și rutau toate cererile prin metode de acțiune. MVC este încă complet suportat și este un model testat în luptă cu convenții puternice, dar pentru multe scenarii este mai rapid să se raționeze despre Razor Pages, deoarece codul care încarcă și procesează o pagină se află fizic lângă markup-ul său, în loc să fie îngropat într-un controller separat.
Chiar dacă Razor Pages mută accentul de la controlere, folosește în continuare același motor de vizualizare Razor și acceptă atât HtmlHelpers, cât și TagHelpers pentru a genera HTML dinamic. TagHelpers sunt deosebit de utile: extind etichetele HTML normale cu atribute precum asp-action, asp-controller or asp-route astfel încât să puteți conecta linkuri și formulare la endpoint-uri backend fără a scrie o grămadă de URL-uri manuale sau JavaScript inline.
Pentru dezvoltatorii care cunosc deja JavaScript și au utilizat framework-uri SPA, Razor Pages oferă o abordare hibridă: HTML randat pe server pentru primele încărcări rapide și SEO, cu JavaScript și biblioteci front-end suprapuse acolo unde este nevoie. Nu ești blocat în sau împotriva vreunui framework JS anume și poți păstra backend-ul și frontend-ul în aceeași soluție, ceea ce simplifică implementarea și întreținerea.
Crearea și rularea unei aplicații web Razor Pages
Când creați un nou proiect ASP.NET Core Razor Pages utilizând Visual Studio, Visual Studio Code sau Rider, șablonul conectează o aplicație minimală, dar completă, inclusiv Program.cs, folderul Pages, fișierele de configurare și rădăcina web statică. Primești imediat un site funcțional pe care îl poți rula și apoi îl poți transforma în ceva mai sofisticat, cum ar fi un catalog de filme sau orice altă aplicație bazată pe date.
Înainte de a rula aplicația pe HTTPS, ASP.NET Core trebuie să utilizeze un certificat de dezvoltare în care sistemul dvs. de operare are încredere, iar prima dată când rulați proiectul, este posibil să vedeți o casetă de dialog care vă solicită să îl aveți încredere. Când apare dialogul respectiv, alegerea Da indică faptul că sunteți de acord cu utilizarea certificatului de dezvoltare locală pentru traficul HTTPS pe mașina dvs., care este necesar pentru testarea corectă a endpoint-urilor securizate fără avertismente din browser.
Pe Windows, macOS sau Linux, Visual Studio Code vă permite să lansați aplicația apăsând Ctrl+F5 pentru a rula fără depanare sau utilizând panoul Executare și Depanare dacă doriți să atașați depanatorul. Prima dată, VS Code vă poate solicita să selectați un tip de depanator, cum ar fi C#, .NET 5+ și .NET Core sau o configurație specifică de lansare, cum ar fi C#: RazorPagesMovie [https] RazorPagesMovie în funcție de versiunea .NET și de configurația spațiului de lucru.
După lansare, browserul implicit se deschide la o adresă URL similară cu https://localhost:<port>, unde portul este atribuit aleatoriu sau specificat în launchSettings.json și vă uitați la pagina principală servită de aplicația Razor Pages. În unele șabloane, veți vedea în schimb http://localhost:5001 sau un alt port; esențial este că localhost indică faptul că este propria mașină și nu o gazdă externă.
După ce ați terminat testarea, puteți opri aplicația care rulează din IDE: în Visual Studio Code, utilizați meniul Executare și selectați Oprire depanare sau apăsați Schimba+F5, în timp ce în Visual Studio pentru Mac utilizați Debug > Oprire depanare. Aceasta oprește instanța serverului web Kestrel care a fost pornită pentru sesiune și eliberează portul pentru alte execuții.
Înțelegerea structurii proiectului: foldere și fișiere cheie
Aplicațiile Razor Pages din lumea reală sunt organizate în jurul câtorva foldere și fișiere de configurare importante cu care veți lucra constant: Pages, wwwroot, appsettings.json și Program.cs (și în versiunile mai vechi, Startup.cs). Navigarea cu aceste materiale este crucială, deoarece practic fiecare tutorial, exemplu sau proiect de producție folosește aceleași convenții.
Folderul Pages este inima unui proiect Razor Pages, conținând toate paginile .cshtml și fișierele code-behind .cshtml.cs aferente, împreună cu aspectul partajat și vizualizările parțiale. Fiecare pereche de pagini (de exemplu, Index.cshtml și Index.cshtml.cs) reprezintă un punct final apelabil în aplicația dvs. și fișiere speciale care încep cu un subliniere, cum ar fi _Layout.cshtml, definesc conținut reutilizat pe mai multe pagini.
Fișierul de aspect, denumit de obicei _Layout.cshtml, definește partea Chrome a site-ului dvs., cum ar fi bara de navigare superioară, subsolul și notificarea privind drepturile de autor și oferă un loc pentru a reda corpul fiecărei pagini individuale. Când modifici aspectul, modifici instantaneu aspectul tuturor paginilor Razor care îl utilizează, așa că este locul ideal pentru editarea meniurilor, a brandingului și a scripturilor sau stilurilor partajate.
Folderul wwwroot este rădăcina web desemnată unde se află resursele statice, inclusiv CSS, JavaScript, imagini și fișiere HTML simple care pot fi servite direct de serverul web. Orice element plasat sub wwwroot poate fi accesat de browser (în funcție de configurația fișierului static), ceea ce îl face locul potrivit pentru foile de stil ale site-ului, bibliotecile client-side și imaginile la care se face referire în markup-ul dvs.
Configurația aplicației este de obicei stocată în appsettings.json (și variante specifice mediului, cum ar fi appsettings.Development.json), care conțin setări precum șiruri de conexiune și semnalizatoare de funcții. Sistemul de configurare ASP.NET Core încarcă aceste fișiere și le îmbină cu variabile de mediu și alți furnizori, simplificând legarea secțiunilor la clase de opțiuni puternic tipizate din cod.
Program.cs și conducta ASP.NET Core
Fișierul Program.cs conține punctul de intrare pentru aplicația Razor Pages și definește modul în care sunt configurate gazda web, serviciile și canalul middleware înainte ca prima solicitare să ajungă pe site-ul dvs. În versiunile moderne de ASP.NET Core, Program.cs utilizează un model simplificat de „găzduire minimală” cu o instrucțiune de nivel superior care creează un WebApplicationBuilder și apoi construiește și configurează WebApplication instanță.
Modelul tipic în Program.cs începe cu var builder = WebApplication.CreateBuilder(args); care configurează o gazdă cu valori implicite comune, apoi apelează builder.Services.AddRazorPages(); pentru a înregistra Razor Pages cu containerul de injecție a dependenței. După configurarea serviciilor, var app = builder.Build(); creează obiectul aplicației pe care apoi îl conectați cu middleware și endpoint-uri.
Gestionarea erorilor și comportamentul de securitate depind în mare măsură de mediu, așa că de obicei vedeți o verificare a mediului ca if (!app.Environment.IsDevelopment()) pentru a activa funcții de nivel de producție. În această condiție veți găsi în mod normal app.UseExceptionHandler("/Error"); care trimite erorile netratate către o pagină de eroare dedicată și app.UseHsts(); care activează HTTP Strict Transport Security (HSTS) pentru a instrui browserele să utilizeze întotdeauna HTTPS pentru domeniul dvs.
Canalul middleware este apoi asamblat cu apeluri precum app.UseHttpsRedirection();, app.UseStaticFiles(); or app.MapStaticAssets();, app.UseRouting(); și opțional app.UseAuthorization(); urmate de mapări ale punctelor finale. Redirecționarea HTTPS forțează actualizarea cererilor HTTP nesigure la HTTPS, middleware-ul pentru fișiere statice (sau maparea statică a resurselor, mai nouă, din .NET 9) permite servirea directă a resurselor de la wwwroot, iar rutarea decide ce punct final gestionează fiecare adresă URL primită.
În cele din urmă, paginile Razor sunt conectate la rutare cu app.MapRazorPages(); opțional înlănțuit cu .WithStaticAssets(); în șabloanele mai noi pentru a integra optimizarea activelor statice, iar aplicația este pornită folosind app.Run();. În acel moment, aplicația ascultă pe porturile configurate, iar serverul Kestrel este gata să gestioneze cereri reale, fie local în dezvoltare, fie pe o gazdă de producție, cum ar fi IIS, Azure App Service sau Docker.
Pagini Razor, modele și modele de vizualizare în aplicații reale
În spatele fiecărei aplicații Razor Pages, practic non-triviale, se află un set de modele de domeniu și modele de vizualizare care reprezintă datele dvs. și modul în care acestea sunt afișate, indiferent dacă gestionați un catalog de filme, un blog sau un tablou de bord de afaceri. Modelele se mapează de obicei îndeaproape cu entitățile bazei de date, în timp ce modelele de vizualizare pot fi adaptate la un anumit ecran sau flux de utilizator, combinând mai multe modele sau valori preformatate pentru o randare mai ușoară.
Un flux de lucru comun de dezvoltare este de a începe cu clase C# simple care utilizează câmpuri și semnături de metode ca stub-uri și de a le dezvolta treptat în modele adecvate cu proprietăți încapsulate, atribute de validare și logică. Instrumente precum JetBrains Rider facilitează această evoluție cu acțiuni de intenție care convertesc automat câmpurile în proprietăți, creează tipuri derivate pentru ierarhii de moștenire și aplică alte refactorizări pe măsură ce rafinați modelul de obiect.
Moștenirea și interfețele ajută la impunerea unei structuri coerente pentru modelele dvs., aliniindu-le cu regulile de business reale și permițând polimorfismul în care anumite comportamente sunt partajate, dar implementările diferă. De exemplu, ați putea avea o bază ContentItem tip cu derivate Movie, Series și Documentary clase, fiecare cu diferențe subtile, dar un contract comun utilizat în întreaga aplicație.
Odată ce modelele sunt configurate, paginile Razor sau vizualizările MVC pot fi create fie manual, fie prin intermediul instrumentelor de scaffolding care generează pagini pentru listarea, crearea, editarea și ștergerea entităților. Schelarea accelerează dramatic dezvoltarea timpurie și asigură că rutarea, legarea modelului și validarea sunt conectate corect, pe care le puteți personaliza apoi cu propriul markup și stil.
Sintaxa Razor utilizată în fișierele .cshtml se combină perfect cu modelele puternic tipizate și modelele de vizualizare, permițându-vă să afișați date, să rulați bucle și condiții și să generați linkuri și formulare folosind HtmlHelpers sau TagHelpers fără a pierde siguranța la compilare. Această combinație de C# și markup păstrează multă logică pe partea de server, dar produce în continuare HTML curat în browser, care se integrează perfect cu CSS și JavaScript.
Lucrul cu sintaxa Razor, TagHelpers și navigare în Rider
Sintaxa Razor este un strat ușor peste HTML care se activează ori de câte ori @ apare simbolul , facilitând încorporarea expresiilor C#, a instrucțiunilor sau a apelurilor helper direct în markup. Puteți parcurge liste de elemente, puteți afișa sau ascunde elemente în funcție de condiții sau puteți afișa valori și date formatate fără a scrie un limbaj de șablon separat sau a presăra JavaScript peste tot.
TagHelpers se simt ca o extensie naturală a HTML-ului, unde atributele speciale care încep cu asp- modificați comportamentul sau rezultatul elementelor, înlocuind adesea metodele HtmlHelper mai vechi și eliminând necesitatea utilizării lipiciului de script inline. Exemplele includ asp-action și asp-controller pentru a direcționa etichetele ancoră și formularele către acțiuni specifice sau pentru a direcționa atribute precum asp-route-id pentru a transmite parametrii în mod curat în URL-uri.
Suportul IDE contează foarte mult atunci când te afli adânc în HTML, iar Rider oferă funcții utile, cum ar fi breadcrumb-urile în partea de jos a editorului, pentru a afișa locația curentă în structura documentului. Breadcrumb-urile pot fi personalizate în Preferințe sau Opțiuni din secțiunea Editor și fac navigarea prin fișiere Razor lungi cu etichete imbricate mult mai puțin dificilă.
În proiectele MVC, Rider înțelege și convențiile care leagă controlerele, acțiunile și vizualizările, astfel încât trecerea cursorului peste rezultatele acțiunilor vă poate arăta posibilele căi de vizualizare și Ctrl + Click (Sau Cmd-Clic pe macOS) sare direct la fișierul .cshtml corespunzător. Scurtături precum Ctrl + B or Cmd-B oferă o modalitate rapidă de a naviga prin baza de cod fără a căuta prin exploratoarele de soluții.
Dincolo de instrumentele specifice Razor, Rider include o gamă largă de soluții și remedieri rapide pentru HTML, CSS și JavaScript, care vă ajută să scrieți cod client-side curat și bine structurat în același IDE ca și backend-ul C#. Această integrare strânsă poate economisi o mulțime de schimbări de context atunci când se construiesc interfețe de utilizator complexe și interactive, care se bazează în continuare pe vizualizări sau pagini Razor randate pe server.
Depanarea paginilor Razor și a aplicațiilor ASP.NET Core
Depanarea este o activitate zilnică în dezvoltarea web, iar aplicațiile ASP.NET Core care rulează Razor Pages nu fac excepție, așadar este esențial să aveți un suport puternic pentru depanare în IDE. Atât Visual Studio, cât și Rider oferă depanatoare interactive care se pot atașa la procesul Kestrel, pot parcurge pas cu pas codul C#, pot inspecta variabile și pot evalua expresii în timp ce aplicația rulează.
Depanatorul Rider pe Windows acceptă funcțiile Editare și Continuare, care vă permit să modificați codul în timp ce aplicația este întreruptă la un punct de întrerupere și să aplicați modificările fără a reporni întreaga sesiune de depanare. Această capacitate de a corecta mici greșeli sau de a experimenta în timpul unei rulări de depanare accelerează semnificativ depanarea, în special în proiectele mari cu timpi de pornire considerabili.
Pagina implicită de excepții pentru dezvoltatori din ASP.NET Core este activată automat atunci când mediul este setat la Dezvoltare, oferindu-vă o urmărire detaliată a stivei, informații despre solicitări și diagnostice ori de câte ori apar excepții netratate. Această vizualizare este extrem de utilă în timpul depanării locale, dar periculoasă în producție, deoarece poate divulga detalii interne despre aplicație și mediu.
Pentru a proteja informațiile sensibile, mediile de producție și de testare dezactivează de obicei pagina de excepții pentru dezvoltatori și utilizează în schimb ruta configurată pentru tratarea excepțiilor, adesea /Error, pentru a afișa un ecran de eroare ușor de utilizat în timp ce se înregistrează detaliile reale pe server. Acest comportament este controlat în Program.cs prin verificarea mediului și apelurile către UseExceptionHandler și UseHsts.
Când lucrurile ies cu adevărat de pe șine și tutorialele nu se potrivesc comportamentului tău, este adesea util să compari proiectul tău cu un exemplu despre care se știe că este bun, furnizat de Microsoft sau de alte surse autorizate. Multe tutoriale oficiale Razor Pages publică un proiect exemplu finalizat pe care îl puteți vizualiza sau descărca pentru a compara codul cu propriul cod și a identifica configurațiile lipsă, greșelile de scriere sau fișierele plasate greșit.
Publicarea și implementarea aplicațiilor ASP.NET Core Razor reale
Livrarea aplicației Razor Pages este momentul în care toată structura și configurația anterioară merită, deoarece ASP.NET Core acceptă mai multe opțiuni de implementare care se potrivesc diferitelor medii de găzduire și fluxuri de lucru. Indiferent dacă preferați IIS pe Windows, containerele Linux în Docker sau o platformă gestionată precum Azure App Service, procesul de publicare poate fi condus de MSBuild și integrat în conductele dvs. CI/CD.
Atât Visual Studio, cât și Rider oferă profiluri de publicare care pot împacheta aplicația și o pot implementa în IIS folosind Web Deploy (MSDeploy), o pot copia într-un folder local sau de rețea sau o pot trimite direct către un server la distanță prin FTP, FTPS sau SFTP. Crearea unui profil de publicare codifică setările de implementare, astfel încât publicările viitoare să fie la fel de simple ca alegerea profilului și clicul pe un buton sau rularea unei comenzi.
Pentru scenariile în cloud, Azure App Service este o țintă populară, iar IDE-urile integrează instrumente Azure pentru a crea și publica aplicații web direct din proiect, din nou bazându-se pe MSBuild și MSDeploy. Această abordare menține consecvența construirii și implementării între mediile locale și cele din cloud și poate fi automatizată în Azure DevOps, GitHub Actions sau alte sisteme CI.
Docker este o altă opțiune de primă clasă pentru ASP.NET Core, permițându-vă să containerizați aplicația Razor Pages, astfel încât aceasta să poată fi rulată previzibil în orice mediu care acceptă containere. Rider și Visual Studio vă pot ajuta să generați fișiere Dockerfile și configurații docker-compose, permițând un flux de lucru în care dezvoltați, depanați și implementați aplicația în containere, fie local, fie în orchestratoare precum Kubernetes.
Indiferent de țintă, pasul de publicare compilează codul C#, grupează vizualizările Razor, copiază resursele statice și, în funcție de setări, poate genera și un runtime autonom, astfel încât mașina gazdă să nu necesite o instalare .NET partajată. Această grupare este cea care transformă proiectul tău de dezvoltare într-un artefact implementabil, gata de utilizare de către utilizatori reali.
Combinând toate aceste componente - de la certificatele de dezvoltare și Program.cs, trecând prin Pages și wwwroot, până la depanare și publicare - Razor Pages oferă o modalitate pragmatică de a construi aplicații web ASP.NET Core în lumea reală, ușor de întreținut, performante și confortabile pentru dezvoltatorii cărora le place deja să lucreze în C# și nu sunt pregătiți să mizeze pe deplin pe un framework cu o singură pagină pentru fiecare situație.
