ASP.NET è sul mercato da 4 anni e poco più, ormai, eppure ci sono ancora tanti sviluppatori che sono rimasti a Classic ASP.

Il motivo principale di questa scelta è probabilmente dettata dal fatto che in realtà, come ben sapranno queste persone, le uniche quattro cose in comune tra ASP ed ASP.NET sono le tre lettere nel nome e quello a cui servono: creare pagine web.

Di sicuro, comunque, c'è che la versione 2.0 di ASP.NET è l'ultima buona occasione perché chi è ancora rimasto fermo ad ASP cominci a pensare che è arrivato il momento di passare stabilmente ad ASP.NET. Il motivo principale è che ASP.NET 2.0 nasconde maggiormente certi dettagli interni (i cosiddetti internals) rispetto alle versioni 1.x, favorendo dunque un approccio più soft.

Questo però, sia chiaro, non esclude che un serio approfondimento vada fatto comunque, altrimenti il rischio che si corre è quello di non capire perché alcune cose vadano in un certo modo.

Questo articolo non è dunque un'introduzione ad ASP.NET 2.0 (ne abbiamo già pubblicate tante, le trovate nelle nostre guide), quanto una semplice guida per chi abbia già approfondito ASP.NET e si trovi nella necessità di migrare applicazioni reali, o piuttosto il proprio modo di operare.

Tutto quello che leggerete nasce infatti dalla mia esperienza, dato che ho fatto questo salto anche io, seppure non appena ASP.NET 1.0 è stato rilasciato.

Prima di cominciare: gli strumenti

Con ASP un editor vale l'altro, con ASP.NET no. Quello che fa davvero la differenza è Visual Studio 2005, che è disponibile in tante versioni.
Se non avete un abbonamento MSDN, potete buttarvi sulla versione Express, del tutto gratuita e di cui si può fare il download da questa pagina.

Il rendering cambia forma

Nelle applicazioni ASP l'unico modo sensato di fare output di informazioni dal server è utilizzare Response.Write, o una sintassi equivalente come <%= %>. Questo avviene essenzialmente perché il modello che sta sotto è procedurale, del tutto piatto.

D'altra parte ASP basa il proprio engine su un motore di scripting che interpreta al volo il codice scritto in VBS. Questo vuol dire che in base all'ordine in cui si trova una certa informazione sulla pagina, così questa viene scritta nel buffer di output. Ovviamente è sempre e comunque possibile utilizzare un po' di istruzioni per introdurre un output differente, magari organizzando il codice in modo tale che vengano utilizzate funzioni o subroutine. La sostanza però è che il modello fa sì che sia possibile introdurre il famigerato effetto spaghetti code, dove in pratica il markup è mischiato al codice server side, fatto che in alcuni scenari porta a non poca confusione.

Inoltre non c'è una reale gestione degli eventi, caratteristica che, tanto per fare un esempio, nel bene e nel male viene utilizzata da svariati anni nello sviluppo di applicazioni per Windows basate su Visual Basic.

D'altro canto ASP.NET è basato su un modello chiamato event driven, perché tutto è basato su eventi. Perfino la pagina ne ha diversi, che si verificano in determinate condizioni.

Così accade che in realtà il rendering venga demandato ad un particolare evento, chiamato appunto Render, che la pagina così come tutti i controlli contenuti, invocano per produrre l'output sullo stream di risposta.

Questo cambiamento fa sì che Response.Write nelle pagine ASP.NET non si usi per una prima semplice ragione: scriverebbe il testo in un'area a caso. Basta provare questo script per farsene un'idea:

Questo è il testo della pagina
<SCRIPT RUNAT="SERVER" LANGUAGE="VB">
Sub Page_Load()
  Response.Write("Vediamo dove va a finire")
End Sub
</SCRIPT>

L'output prodotto riporta la frase scritta nell'evento Page_Load in cima alla pagina, prima dell'HTML. Il motivo di questo comportamento è che l'evento Page_Render, che è quello che effettivamente prende il contenuto della pagina e lo scrive nel buffer di risposta, viene invocato successivamente.

Il modello dichiarativo di ASP.NET

In realtà Response.Write non si utilizza più anche e soprattutto perché c'è un nuovo modello dichiarativo, che introduce il concetto di control.

Un control è essenzialmente un oggetto che viene inserito all'interno della pagina e che in base al ruolo per cui è stato creato è in grado di produrci una determinata funzionalità. C'è tutta una spiegazione dietro che non vale la pena di ripetere, perché la trovate già scritta in questo articolo.

Per ricapitolare, nella pagina ci sono dei controls che possono essere programmati, che hanno eventi e possono pertanto subire modifiche in base alle nostre necessità.

Vediamo un esempio di form con Classic ASP e vediamo come il nuovo modello favorisca una scrittura del codice più pulito (oltre che ad essere l'unico tra i due davvero Object Oriented).

<%
mome = Request("nome")
cognome = Request("cognome")
 
if Len(nome)>0 and Len(cognome)>0 then
 
%>
Hai inserito <%=nome & " " & cognome%>
<%
Else
 
%>
<form method="post">
Nome: <input type="text" name="nome" />

Cognome: <input type="text" name="cognome" />

<input type="submit" />
</form>
<%end if%>

<SCRIPT RUNAT="SERVER" LANGUAGE="VB">
Sub Page_Load()
  If Page.IsPostBack then
    Result.Text = nome.Text & " " & cognome.Text
    ResultPanel.Visible = true

TheForm.Visible = false
  End if
End Sub
</SCRIPT>
<asp:panel id="ResultPanel" runat="server">
Hai inserito <asp:label id="Result" runat="server" />
</asp:panel>
 
<form  runat="server" id="TheForm">
Nome: <input type="text" id="nome" runat="server" />

Cognome: <input type="text" id="cognome" runat="server" />

<input type="submit" />
</form>

La differenza sta tutta nel fatto che adottando un opportuno modello, denominato CodeFile, si riesce addirittura a tenere del tutto separato il markup HTML dal codice server side. E questo si traduce in una pulizia decisamente maggiore della pagina, anche nel caso in cui si decida di usare, come abbiamo fatto noi, il cosiddetto modello inline, dove il codice è nella pagina stessa e non in un file separato (anche se poi è in un'area separata, per cui il concetto resta del tutto valido).

Il vantaggio di un modello ad oggetti consistente tra i vari controls fa sì che si possa accedere più facilmente alle proprietà di un control. Basta pensare a quanto sia comoda una DropDownList rispetto all'equivalente normale controllo HTML.

In più, come nell'esempio, tutti i controls possono essere nascosti attraverso la proprietà Visibile, che fa sì che sia davvero possibile cambiare faccia alla pagina durante i vari PostBack.

Ed è questo il motivo per cui la pagina è tutto sommato autosufficiente dal punto di vista della singola operazione: di fatto è possibile nascondere blocchi e fare in modo che una certa operazione, a differenza di ASP, venga fatta all'interno di una sola pagina, con benefici soprattutto dal punto di vista della manutenzione, perché si può dire addio alla presenza di tanti file quanti sono i passaggi che compongono una particolare routine.

Per chi viene da ASP, dunque, la vera difficoltà è rappresentata dal fatto che il modello di sviluppo è profondamente differente, dato che non si è per niente abituati a questo approccio. Il sistema più semplice per abituarsi ad utilizzare ASP.NET è quello di continuare a scrivere la struttura delle pagine nella consueta forma, aggiungendo l'attributo runat="server" a quei controls che si vogliono effettivamente utilizzare lato server, come input box.

In questo modo il passaggio è graduale e non c'è bisogno di stravolgere tutto, perché i cosiddetti Web Controls possono essere presi in considerazione anche in un secondo momento, quando cioè si avrà maggiore dimestichezza con questo approccio.