Le Razor Pages sono usate per creare pagine Web. A differenza dell'approccio tradizionale di sviluppo Model-View-Controller (MVC), in cui si creano controller separati per gestire le richieste dei client e le view per la presentazione dei dati, le Razor Pages consentono di combinare logica di gestione delle richieste e presentazione in un'unica pagina.
Quando una richiesta viene ricevuta da un'applicazione ASP.NET Core passa attraverso il pipeline dei middleware fino a quando un componente può gestirla. Normalmente, l'ultimo middleware nella pipeline è l'endpoint middleware. Questo componente lavora insieme a quello di routing per abbinare il percorso dell'URL di una richiesta a una rotta configurata, che definisce quale Razor Page invocare. Una volta selezionata una Razor Page, il middleware di routing annota la Razor Page selezionata nel contesto HttpContext della richiesta e continua l'esecuzione del pipeline dei middleware. Alla fine, la richiesta raggiungerà il middleware di endpoint. Il middleware di endpoint esegue la Razor Page per generare la risposta in HTML e la invia al browser.
Razor Pages in ASP.NET Core
Le Razor Pages sono state introdotte per la prima volta in ASP.NET Core 2.0 come un nuovo modello di programmazione per la creazione di pagine Web dinamiche. Da allora, hanno subito diverse evoluzioni fino ad oggi.
Con il rilascio di ASP.NET Core 3.0 nel settembre 2019, sono stati introdotti sostanziali miglioramenti alle Razor Pages, tra cui il supporto per la creazione di pagine Web con il routing basato su attributi, il supporto per l'autenticazione e l'autorizzazione basata su politiche e il miglioramento delle prestazioni. L'avvento di ASP.NET Core 3.1 e 5.0, rispettivamente rilasciati nel dicembre 2019 e nel novembre 2020, ha introdotto ulteriori novità. Queste includono il supporto per la validazione dei modelli di pagina, il supporto per l'utilizzo di end point di pagina come API RESTful, e il supporto per l'utilizzo di tag helper.
ASP.NET Core 6.0, attualmente in fase di sviluppo, prevederà il supporto per l'editing in tempo reale delle Razor Pages durante l'esecuzione dell'applicazione.
Convenzioni per le Razor Pages
Le pagine Razor sono memorizzate in file .cshtml (un portmanteau di .cs ed .html) all'interno della cartella Pages del nostro progetto. In generale, il middleware di routing mappa gli URL di richiesta a una singola Razor Page cercando nella cartella Pages una Razor Page con lo stesso percorso. Ad esempio, la pagina MyPage della nostra applicazione corrisponde al percorso MyPage/ nella barra degli indirizzi del browser. Se si guarda all'interno della cartella Pages del progetto, si troverà il file MyPage.cshtml.
Ogni pagina Razor ha un corrispondente modello di pagina, che è una classe C# che definisce il comportamento della pagina. La convenzione per il modello di pagina è quella di avere una classe con lo stesso nome della Razor Page, ma con l'aggiunta del suffisso Model. Ad esempio, se la pagina Razor si chiama MyPage.cshtml, il modello di pagina sarà chiamato MyPageModel.cshtml.cs. Sia la Razor Page che il PageModel si trovano entrambi nella directory Pages dell'applicazione.
Le pagine Razor seguono una convenzione per gestire le richieste HTTP dai client. In particolare, le richieste HTTP GET sono gestite dal metodo OnGet() del modello di pagina, mentre le richieste HTTP POST sono gestite dal metodo OnPost() del modello di pagina. Questi metodi vengono automaticamente chiamati dal framework ASP.NET Core in base all'azione richiesta dal client.
Generare HTML con le Razor Pages
Le Razor Pages utilizzano una sintassi di template chiamata Razor, che combina HTML statico con codice C# dinamico. Vediamo insieme il codice di una Razor Page:
@page
@model PrivacyModel
@{
ViewData["Title"] = "Privacy Policy";
}
<h1>@ViewData["Title"]</h1>
<p>Use this page to detail your site's privacy policy.</p>La direttiva @page sulla prima riga della Razor Page è la più importante. Essa deve sempre essere posizionata sulla prima riga del file, in quanto indica ad ASP.NET Core che il file .cshtml è una Razor Page. Senza non sarà possibile visualizzare correttamente la pagina.
La seconda riga di codice @model PrivacyModel specifica il modello associato a questa Razor Page. In questo caso, il PageModel si chiama PrivacyModel e segue la convenzione standard per la denominazione dei modelli di Razor Pages. Troveremo questa classe nel file Privacy.cshtml.cs della cartella Pages.
La terza riga di codice @{...} è un blocco di codice C# all'interno della Razor Page. In questo caso, viene utilizzato per impostare il titolo della pagina utilizzando la variabile ViewData["Title"] con il valore Privacy Policy.
La quarta riga di codice <h1>@ViewData["Title"]</h1> è una sintassi Razor per visualizzare il valore della variabile @ViewData["Title"] all'interno di un tag HTML h1. La variabile @ViewData["Title"] verrà sostituita con il valore Privacy Policy durante la visualizzazione della pagina.
La quinta riga di codice <p>Use this page to detail your site's privacy policy.</p> è semplice codice HTML che verrà visualizzato come un paragrafo nella Razor Page.
In sintesi, questo codice definisce una Razor Page che ha un modello di PrivacyModel associato e mostra il titolo "Privacy Policy" e un paragrafo di testo sulla pagina.
Gestione della logica delle richieste con i PageModels
Per avere un'idea di come funzionano tipicamente le Razor Pages, vediamo in questo paragrafo il codice di un PageModel. Questa pagina è tratta da un'applicazione di lista delle cose da fare (to do list) ed è utilizzata per visualizzare tutte le attività da svolgere per una determinata categoria (spesa, sport, etc.). In questo momento non ci stiamo focalizzando sulla generazione dell'HTML e quindi, la seguente lista mostra solo il codice dietro il PageModel della Razor Pages.
public class CategoryModel : PageModel
{
private readonly ToDoService _service;
public CategoryModel(ToDoService service)
{
_service = service;
}
public ActionResult OnGet(string category)
{
Items = _service.GetItemsForCategory(category);
return Page();
}
public List<ToDoListModel> Items { get; set; }
}Il codice sopra riportato è presente all'interno di un file, chiamato Category.cshtml.cs, che si trova all'interno della directory Pages del nostro progetto. La classe è chiamata CategoryModel ed eredita dalla classe PageModel, che fa parte del framework Razor Pages in ASP.NET Core. Ha un costruttore che accetta un parametro di tipo ToDoService, che lo assegna a una variabile privata _service. ToDoService è una dipendenza necessaria per questa classe e viene iniettata attraverso la dependency injection nel costruttore. La dependency injection è un pattern comune in ASP.NET Core per gestire le dipendenze tra le diverse parti dell'applicazione.
Il metodo OnGet è chiamato quando la pagina viene richiesta con un metodo HTTP GET. Prende una stringa category come parametro dalla query string dell'URL e utilizza il metodo _service.GetItemsForCategory(category) per ottenere una lista di oggetti ToDoListModel associati a quella categoria. Questa lista viene assegnata alla proprietà Items della classe e infine viene restituito il risultato della pagina con il metodo Page().
La proprietà Items è pubblica e di tipo List<ToDoListModel> e viene utilizzata per memorizzare gli oggetti ToDoListModel associati a una specifica categoria. La proprietà è accessibile dalla vista Razor associata a questa classe e può essere utilizzata per visualizzare i dati nella pagina. In sintesi, questa classe dietro la Razor Page Category.cshtml gestisce la logica per ottenere una lista di oggetti ToDoListModel associati a una categoria specifica e li rende disponibili alla vista Razor per essere visualizzati nella pagina.
Il PageModel mostrato sopra rivela un pattern comune. Il gestore della pagina è il controller centrale per le Razor Page. Riceve un input dall'utente (la stringa category), chiama il "cuore" dell'applicazione (il ToDoService) e passa i dati (esponendo la proprietà Items) alla vista Razor, che genera la risposta HTML. Se notiamo, sembra proprio il pattern architetturale del MVC, utilizzato in diversi framework come Django, Rails e Spring MVC.
Conclusioni
In questa lezione abbiamo visto che quando gli utenti comunicano con la nostra applicazione Web, stanno in realtà comunicando con il controller della pagina su cui vogliono intraprendere una qualche interazione. Nelle applicazioni Web, questa interazione assume la forma di una richiesta HTTP. Quindi, quando viene ricevuta la richiesta verso un URL, il controller la gestisce. A seconda della natura della richiesta il controller può compiere una varietà di azioni.
Inoltre, abbiamo parlato del pattern MVC e del fatto che le Razor Pages utilizzano questo approccio architetturale. Tuttavia, ASP.NET Core include anche un framework chiamato ASP.NET Core MVC. Questo framework utilizza controller e metodi di azione al posto delle Razor Pages e degli handler di pagina. Le Razor Pages si basano direttamente sul framework sottostante di ASP.NET Core MVC, utilizzando il framework MVC per il loro funzionamento.
Se lo preferiamo, possiamo evitare completamente le Razor Pages e lavorare direttamente con il framework MVC in ASP.NET Core, che vedremo nella prossima lezione.
