Che cos’è ASP.NET?

ASP.NET è un framework per ap­pli­ca­zio­ni web lato server di Microsoft. Gli svi­lup­pa­to­ri uti­liz­za­no ASP.NET per creare siti dinamici, ap­pli­ca­zio­ni e servizi per il web. Dopo una fase di sviluppo durata un decennio, il framework oggi è di­spo­ni­bi­le come ASP.NET Core.

Ori­gi­na­ria­men­te svi­lup­pa­to da Microsoft, ASP.NET oggi fa parte della .NET Foun­da­tion. Mentre le prime versioni furono ri­la­scia­te come software a pagamento, la versione attuale ASP.NET è un progetto open source.

Quello che co­no­scia­mo oggi come ASP.NET è il risultato di un processo di sviluppo durato un decennio. Da qui l’evo­lu­zio­ne da ASP, ad ASP.NET e infine ad ASP.NET Core. Pa­ral­le­la­men­te ai progressi nel settore della tec­no­lo­gia web, nel corso degli anni il framework è cambiato in modo drastico. Qui di seguito vi pre­sen­te­re­mo la storia dello sviluppo di ASP.NET:

Gli “Active Server Pages” (ASP) originari sono stati il primo lin­guag­gio di scripting lato server ri­la­scia­ti da Microsoft. Grazie agli Active Server Pages, dal 1996, è stato possibile creare siti web dinamici su un server. Gli altri linguaggi di scripting si ap­pog­gia­no so­li­ta­men­te a Linux come sistema operativo e a un server web open source come Apache. Microsoft ha posto davanti a loro gli Active Server Pages come com­po­nen­te dell’“Internet In­for­ma­tion Server” (IIS) per Windows.

Le funzioni base di ASP si possono in qualche modo pa­ra­go­na­re a PHP o alle “Java Script Pages” (JSP). Tutti e tre i linguaggi uti­liz­za­no file di modello. I file di modello con­ten­go­no pezzetti di codici ese­gui­bi­li, in­cor­po­ra­ti nei contenuti statici HTML. Il codice è scritto con tag speciali per evitare che si confonda con i vicini HTML. I dialetti specifici di Windows di­spo­ni­bi­li all’epoca e cioè VBScript, JScript e Perl­Script furono uti­liz­za­ti come linguaggi di pro­gram­ma­zio­ne.

Per accedere a un URL at­tra­ver­so il browser (“request”) si esegue un codice sul server. L’ese­cu­zio­ne crea contenuti HTML inseriti in strutture HTML pre­de­fi­ni­te. Il risultato com­ples­si­vo è un documento composto da contenuti statici e dinamici di tipo HTML che è inviato come risposta al browser (“response”) e mostrato all’utente. Ciascuna modifica dei contenuti dei siti, per esempio dopo gli input dell’utente, richiede un nuovo ciclo completo di richiesta e risposta e un nuovo ca­ri­ca­men­to del sito. Di seguito un esempio di codice ASP:

ASP non era ancora un framework ma era uti­liz­za­to piuttosto come una raccolta sparsa di pochi oggetti da cui si creava un sito dinamico:

• Ap­pli­ca­tion
• Request
• Response
• Server
• Session
• ASPError

ASP.NET fu pre­sen­ta­to intorno al 2003 come suc­ces­so­re del classico ASP. Al posto di una raccolta sparsa di oggetti si arrivò a uti­liz­za­re il .NET Framework come struttura base. Questo processo astratto ri­chie­de­va spesso passaggi come l’au­ten­ti­ca­zio­ne e l’au­to­riz­za­zio­ne degli utenti e l’accesso al database. Nel complesso ASP.NET si può pa­ra­go­na­re a grandi linee con i framework di Java come “Struts” o “Spring”.

Le funzioni decisive di ASP.NET furono i “Web Forms” che permisero ai pro­gram­ma­to­ri esperti di Windows di pro­gram­ma­re siti dinamici. Gli svi­lup­pa­to­ri potevano oscurare i mec­ca­ni­smi di funzione del web e con­ti­nua­re ad attingere ai flussi di lavoro e agli ambienti di sviluppo già noti. Furono impiegati in par­ti­co­la­re degli strumenti visivi esclusivi di Windows per lo sviluppo rapido di ap­pli­ca­zio­ni (“Rapid Ap­pli­ca­tion De­ve­lo­p­ment”, RAD).

I Web Forms hanno permesso agli svi­lup­pa­to­ri di Windows di entrare ra­pi­da­men­te nel mondo della pro­gram­ma­zio­ne web. Allo stesso tempo, però, questo modello ha limitato la misura dei controlli sui siti HTML rea­liz­za­ti. Con ASP.NET MVC si aggiunse presto un modello di sviluppo al­ter­na­ti­vo che seguiva il modello stabilito “Model View Con­trol­ler” (MVC) e per­met­te­va una se­pa­ra­zio­ne netta degli elementi (“Se­pa­ra­tion of concerns”). Vicino al framework ri­vo­lu­zio­na­rio “Ruby on Rails”, ASP.NET MVC offrì la funzione dello “Scaf­fol­ding” (let­te­ral­men­te: im­pal­ca­tu­ra) di un progetto.

Nel frattempo, ASP.NET è stato so­sti­tui­to dal suc­ces­si­vo “ASP.NET Core”. Nell’uso quo­ti­dia­no, però, i due nomi sono spesso uti­liz­za­ti come sinonimi.

Il rilascio di ASP.NET Core ha rap­pre­sen­ta­to un cambio di rotta nell’or­ga­niz­za­zio­ne del framework. Nell’ambito del passaggio pro­gres­si­vo di Microsoft, lo sviluppo di ASP.NET Core è stato affidato alla tutela della .NET Foun­da­tion. Il testo fonte del progetto è regolato da una licenza open source.

Sul piano tecnico, ASP.NET Core è una versione ri­di­se­gna­ta di ASP.NET 4.0 che ha messo insieme elementi di ASP.NET generati dalla crescita organica, per­met­ten­do lo sviluppo di progetti ASP.NET Core e l’hosting al di fuori degli eco­si­ste­mi Windows. Con Windows si utilizza ASP.NET Core su un framework .NET, sugli altri sistemi operativi invece il framework .NET Core.

Di pari passo con gli sviluppi della tec­no­lo­gia web, ASP.NET Core è com­pa­ti­bi­le con il cloud. Come servizi di hosting per ASP.NET, oltre ai tra­di­zio­na­li Internet In­for­ma­tion Server (IIS) offerti da Windows, si uti­liz­za­no anche ambienti aperti di sviluppo server e i container. Il framework supporta codici lato client e i modelli moderni della pro­gram­ma­zio­ne reattiva. Così ASP.NET Core si avvicina ai framework Ja­va­Script come React.

Il framework ASP.NET permette di rea­liz­za­re i progetti web più disparati tra cui siti e ap­pli­ca­zio­ni web dinamici, come le “Single Pages Apps” (SPA). Ori­gi­na­ria­men­te, era possibile applicare servizi basati sul web come API e sistemi di co­mu­ni­ca­zio­ne in tempo reale. Nel corso degli anni, hanno trovato impiego per i vari scopi diversi modelli che vi mo­stre­re­mo in seguito of­fren­do­vi una pa­no­ra­mi­ca dello sviluppo storico.

A partire dal 2000, con i progressi della tec­no­lo­gia web, sono stati integrati nuovi modelli per lo sviluppo con ASP.NET. Potete im­ma­gi­nar­li come se fossero una cassetta degli attrezzi: per diversi progetti sono a di­spo­si­zio­ne diversi attrezzi. In base alle esigenze è possibile combinare più modelli all’interno di un progetto. Con il rilascio di ASP.NET Core è stato possibile mettere insieme i numerosi modelli di pro­gram­ma­zio­ne a crescita organica sem­pli­fi­can­do la scelta di quelli più adatti.

I classici Web Forms per­met­to­no di mettere insieme pagine a partire da elementi pre­de­fi­ni­ti con un incastro di elementi grafici dove i singoli com­po­nen­ti sono po­si­zio­na­ti tramite funzione drag&drop. Gli svi­lup­pa­to­ri esperti nella pro­gram­ma­zio­ne di Windows hanno ap­prez­za­to par­ti­co­lar­men­te i Web Forms che gli per­met­te­va­no di uti­liz­za­re strumenti già noti per il “Rapid Ap­pli­ca­tion De­ve­lo­p­ment” (“sviluppo rapido delle ap­pli­ca­zio­ni”, RAD) con la dif­fe­ren­za che il prodotto finale non creava un’ap­pli­ca­zio­ne di Windows ma un sito dinamico.

Il modello dei Web Forms si poggia sul modello di Microsoft di classe code-behind che comporta una divisione degli elementi:

• I file di modello con l’esten­sio­ne .aspx de­fi­ni­sco­no la struttura HTML di un sito e con­ten­go­no caratteri jolly per i contenuti creati in modo dinamico.
• La vera logica di pre­sen­ta­zio­ne dell’ap­pli­ca­zio­ne è de­po­si­ta­ta in un file separato con l’esten­sio­ne .aspx.cs o .aspx.vb che rap­pre­sen­ta il file di classe code-behind che gli dà il nome.
• Il client richiede il file .aspx di­spo­ni­bi­le in basso all’URL. Sul server si combinano gli elementi statici e dinamici. Il documento HTML che ne risulta è inviato al client.
• Con gli input dall’utente sulla pagina sono trasmessi i dati allo stesso URL tramite richiesta GET o POST e rie­la­bo­ra­to il file di classe code-behind.

Per im­ple­men­ta­re la logica di pre­sen­ta­zio­ne si utilizza un modello orientato agli oggetti: il file di classe code-behind definisce una classe derivata. So­li­ta­men­te si utilizza il lin­guag­gio di pro­gram­ma­zio­ne C# o Visual Basic. È in­te­res­san­te che il file di classe code-behind debba essere pre­com­pi­la­to una volta sola per­met­ten­do un’ese­cu­zio­ne più rapida e una maggiore re­si­sten­za in caso di errori durante l’apertura della pagina.

Di­ver­sa­men­te dall’ASP ori­gi­na­rio, i Web Forms hanno rap­pre­sen­ta­to un passo decisivo in direzione della divisione degli elementi. Nell’ASP le parti statiche HTML e i codici si trovavano insieme nello stesso file di classe code-behind mentre i Web Forms sono riusciti a dividere i file di template e i file di classe code-behind. Con la versione ASP.NET MVC ad ASP.NET è stato aggiunto un nuovo modello di pro­gram­ma­zio­ne che ha permesso lo sviluppo web secondo il modello Model View Con­trol­ler (MVC).

Il modello MVC divide tra loro la logica di pre­sen­ta­zio­ne (“Model”), il template di rap­pre­sen­ta­zio­ne (“View”) e gli input dell’utente (“Con­trol­ler”). Uno dei vantaggi di MVC è la pos­si­bi­li­tà di ve­ri­fi­ca­re meglio i singoli elementi. Inoltre, la divisione degli elementi permette di uti­liz­za­re meglio i diversi con­trol­ler. Invece di inviare tutti gli input dall’utente a un unico URL e caricare il sito daccapo, si utilizza, ad esempio, lo strumento AJAX tramite jQuery che permette di ri­ca­ri­ca­re nuo­va­men­te parti di una pagina. ASP.NET Core MVC ha portato avanti la tra­di­zio­ne di ASP.NET MVC fino ad arrivare alla versione attuale del framework.

ASP.NET Web Forms e ASP.NET MCV sono molto adatti per creare siti complessi. Se avete bisogno di diverse pagine con elementi che si ripetono, vanno bene entrambi i modelli di pro­gram­ma­zio­ne. E cosa fare invece se non ci servono? Im­ma­gi­nia­mo di dover rea­liz­za­re un sito semplice composto da una pagina singola o da po­chis­si­me pagine. Ci sono un paio di elementi dinamici, ma il focus centrale è rivolto piuttosto a un layout so­fi­sti­ca­to invece che a una logica di pre­sen­ta­zio­ne complessa e al trat­ta­men­to degli input dell’utente. Sarebbe uno spreco definire le proprie classi o sforzarsi per rea­liz­za­re una divisione secondo il modello MVC.

Per i casi in cui la logica di pre­sen­ta­zio­ne deve restare in secondo piano rispetto al layout e al design, si prestano bene le ASP.NET Web Pages. In modo simile ai classici ASP o PHP, all’interno di un file troviamo una com­bi­na­zio­ne di strutture statiche HTML ed elementi dinamici del codice. Qui però si applica una sintassi speciale. Le Web Pages di ASP.NET sono par­ti­co­lar­men­te adatte per creare pagine di de­sti­na­zio­ne.

I modelli di pro­gram­ma­zio­ne pre­sen­ta­ti finora servono tutti a creare contenuti HTML per utenti in carne e ossa. Ma il framework ASP.NET contiene anche modelli che servono a preparare in­fra­strut­tu­re di progetti web. ASP.NET Web API è un modello di pro­gram­ma­zio­ne per creare in­ter­fac­ce API REST. Gli accessi agli endpoint avvengono tramite AJAX mentre per la tra­smis­sio­ne dei file si utilizza il formato JSON o XML.

ASP.NET WebHooks è un’im­ple­men­ta­zio­ne del modello dei WebHooks. I WebHooks per­met­to­no di pub­bli­ca­re e sot­to­scri­ve­re un ab­bo­na­men­to ai risultati che avvengono in un sistema. Può trattarsi, ad esempio, dell’aggiunta di un file o della ricezione di un pagamento. Un abbonato registra la modifica che dovrà avvenire nel sistema. Per farlo inserisce un URL, cioè il WebHook che contiene il nome. Se appare il risultato re­gi­stra­to, il sistema richiama il WebHook e l’abbonato viene informato sul risultato.

SignalR è un framework di co­mu­ni­ca­zio­ne in tempo reale tra client e server. Il framework si basa sul pro­to­col­lo standard WebSocket e permette il tra­sfe­ri­men­to bi­di­re­zio­na­le di dati. I browser che non leggono i WebSocket vengono sup­por­ta­ti da mec­ca­ni­smi di fallback. SignalR si utilizza spesso per rea­liz­za­re servizi di chat tramite browser o software di vi­deo­con­fe­ren­ze.

ASP.NET Core è il suc­ces­so­re di ASP.NET. Il framework ASP.NET Core è stato riscritto daccapo ma presenta un’alta com­pa­ti­bi­li­tà con il suo pre­de­ces­so­re. Quelli che prima erano elementi separati con ASP.NET sono stati riuniti nella versione Core. Per di più alcuni elementi sono stati ri­svi­lup­pa­ti ma hanno mantenuto il loro vecchio nome. Per questo motivo il framework SignalR esiste sia nella versione ASP.NET sia in quella di ASP.NETCore. Qui di seguito vi mo­stre­re­mo gli ultimi sviluppi più im­por­tan­ti di ASP.NET Core.

Con ASP.NET Core MVC sono state riunite le funzioni di ASP.NET MVC e ASP.NET Web API. Questo ha permesso di svi­lup­pa­re ap­pli­ca­zio­ni web dinamiche con in­ter­fac­cia utente modulare sulla base di API usando come struttura generale il framework .NET Core. Con MVC si possono applicare modelli delle versioni .NET API e viceversa.

Le Razor Pages fanno parte di una nicchia simile a quella delle ASP.NET Web Pages e si rivelano utili quando il modello Model-View-Con­trol­ler potrebbe creare inutili overhead. Se, ad esempio, volessimo creare una pagina di de­sti­na­zio­ne, potremmo farlo come Razor Page in modo sem­pli­cis­si­mo. La sintassi di Razor si applica spesso per creare template di siti. Come linguaggi di pro­gram­ma­zio­ne, invece, si usano C# e Visual Basic come per tutto l’universo di .NET.

Guardiamo un esempio di Razor Page. Si nota subito che al posto dei linguaggi soliti del template con i tag di apertura e chiusura del codice si utilizza il carattere @.

Il framework Blazor si poggia sulla sintassi di Razor di cui abbiamo già parlato; in realtà Blazor sta proprio per “Browser + Razor”. Come sug­ge­ri­sce il nome stesso, Blazor si concentra sul browser come runtime system. Con Razor Pages avviene il trat­ta­men­to dell’in­te­ra­zio­ne dell’utente sul server. Blazor permette la pro­gram­ma­zio­ne reattiva, grazie alla quale i singoli elementi delle pagine nel browser rea­gi­sco­no in modo dinamico alle modifiche. Per questi aspetti Blazor si mostra in qualche modo simile a React, Angular e Vue.

Di seguito vi mostriamo un semplice esempio di pro­gram­ma­zio­ne con Blazor. Associamo il valore di un box di ricerca alla variabile Name. Qui si applica la sintassi di Razor:

Oltre alla pro­gram­ma­zio­ne reattiva, Blazor presenta un altro aspetto molto in­te­res­san­te: con We­bas­sem­bly si possono compilare i linguaggi di .NET per l’ese­cu­zio­ne nel browser. Blazor viene spesso definito anche un modello di “.NET in the browser”. Il suo grande vantaggio è non dover scrivere Ja­va­Script per il codice lato client. Lo sviluppo è invece in C# o Visual Basic; il codice può accedere agli elementi noti del framework .NET.

ASP.NET e. ASP.NET Core mettono a di­spo­si­zio­ne un ambiente ben avviato per lo sviluppo di progetti web più disparati. Ne fanno parte linguaggi di pro­gram­ma­zio­ne, editor di codici e IDE nonché strumenti di sviluppo e un eco­si­ste­ma fiorente di pacchetti di­spo­ni­bi­li gra­tui­ta­men­te. Oggi possono essere uti­liz­za­ti anche metodi moderni come la pro­gram­ma­zio­ne reattiva, Web­Soc­ke­ts e We­bAs­sem­bly. Tra­di­zio­nal­men­te, il più grande vantaggio nell’utilizzo di ASP.NET risiedeva nel suo stretto legame con Microsoft e il vendor lock-in collegato. Con la pro­gres­si­va tra­sfor­ma­zio­ne in progetto open source, quest’aspetto è andato via via di­mi­nuen­do.

Gli svi­lup­pa­to­ri con espe­rien­za nella pro­gram­ma­zio­ne negli eco­si­ste­mi di Microsoft sfruttano al meglio i vantaggi di ASP.NET perché riescono ad accedere fa­cil­men­te ai linguaggi, agli strumenti e ai flussi di lavoro già noti. Come sot­to­strut­tu­ra di ASP.NET si applica l’af­fi­da­bi­le framework .NET. Per questo motivo sono di­spo­ni­bi­li gli elementi com­pa­ti­bi­li a un grande numero di casi d’uso. Un grande vantaggio è si­cu­ra­men­te il poter rea­liz­za­re ap­pli­ca­zio­ni complesse in modo rapido ed ef­fi­cien­te.

Il framework .NET ha una struttura modulare e ha come runtime system il “Common Language Runtime” (CLR). Questo permette di uti­liz­za­re diversi linguaggi di pro­gram­ma­zio­ne, a patto che siano com­pa­ti­bi­li con la “Common Language In­fra­struc­tu­re” (CLI). Oltre ai soliti linguaggi orientati agli oggetti C# e Visual Basic, anche il nuo­vis­si­mo lin­guag­gio fun­zio­na­le F# fa parte delle CLI svi­lup­pa­te da Windows. Blazor e We­bAs­se­bly per­met­to­no di eseguire i linguaggi CLI come codice lato client sul browser.

Ori­gi­na­ria­men­te ASP.NET era un software a pagamento sotto il controllo di Microsoft. Oggi invece rap­pre­sen­ta un progetto open source sotto la tutela della .NET Foun­da­tion. Nell’ambito di questo processo sono stati im­ple­men­ta­ti il gestore di pacchetti NuGet e il relativo re­po­si­to­ry di pacchetti gratuito. Si­mil­men­te a NPM o RubyGerms, gli svi­lup­pa­to­ri di ASP.NET hanno a di­spo­si­zio­ne un eco­si­ste­ma di pacchetti gratuiti.

Il grande vantaggio di ASP.NET, e cioè l’utilizzo dell’eco­si­ste­ma specifico di Microsoft, rap­pre­sen­ta al tempo stesso anche il suo grande svan­tag­gio perché lo sviluppo web, di solito, si basa per la maggior parte su piat­ta­for­me, linguaggi e formati gratuiti e aperti. Gli svi­lup­pa­to­ri che si cimentano per la prima volta nell’universo .NET, si trovano davanti a una varietà con­fu­sio­na­ria di versioni e modelli di programmi.

Chi in passato voleva svi­lup­pa­re con il framework ASP.NET, poteva farlo soltanto con Windows. Da qualche anno Microsoft si è aperta verso gli standard più uti­liz­za­ti e le licenze open source. Con la comparsa di ASP.NET Core, lo sviluppo è diventato possibile su tutte le tre grandi famiglie di sistemi operativi cioè Windows, macOS e Linux. Inoltre, è possibile mantenere l’ambiente di sviluppo in un container Docker.

La versione classica di ASP.NET per­met­te­va invece l’hosting solo sui servizi server di Microsoft Internet In­for­ma­tion Server (IIS). Questo rap­pre­sen­ta­va un gran­dis­si­mo svan­tag­gio rispetto agli altri framework per ap­pli­ca­zio­ni web che fun­zio­na­no quasi tutti su Linux. L’hosting di ASP.NET richiede requisiti par­ti­co­la­ri e non è di­spo­ni­bi­le su tutti i provider. Grazie a “Mono”, un’im­ple­men­ta­zio­ne gratuita di .NET, però, fu reso possibile uti­liz­za­re gli altri server web. Il vero punto di svolta è stato la comparsa di .NET Core e di “Open Web Interface for .NET” (OWIN). OWIN di­sac­cop­piò un’ap­pli­ca­zio­ne di ASP.NET dal relativo server web, ab­bat­ten­do in questo modo il più grande scoglio sull’utilizzo di ASP.NET.

Il framework ASP.NET è molto par­ti­co­la­re per quel che riguarda l’hosting. Nor­mal­men­te i framework per ap­pli­ca­zio­ni web basati sui linguaggi PHP, Java, Python o Ja­va­Script operano con i server di Linux. Soltanto che in passato, per l’hosting di ap­pli­ca­zio­ni di ASP.NET era richiesto Windows come sistema operativo del server. In seguito, si è aggiunto il server web di Microsoft chiamato Internet In­for­ma­tion Services (IIS).

Per l’hosting di un’ap­pli­ca­zio­ne di ASP.NET sui server di Windows bisognava se­le­zio­na­re i server dedicati Windows. In questo modello di hosting i provider for­ni­sco­no ma­nu­ten­zio­ne costante dei server, ri­la­scian­do software di ag­gior­na­men­to e sem­pli­fi­can­do no­te­vol­men­te l’hosting di ap­pli­ca­zio­ni di ASP.NET Core che possono essere ospitate dall’IIS e da numerosi altri server. Inoltre, è di­spo­ni­bi­le il server web integrato Kestrel che funziona su Windows, Linux e macOS. I server web più amati come Nginx e Apache possono essere con­fi­gu­ra­ti insieme come Reverse Proxy e uti­liz­za­ti con Kestrel. Per gli utenti di Windows è di­spo­ni­bi­le anche HTTP.sys, un’al­ter­na­ti­va a Kestrel.