ASP.NET 3.5 è una evoluzione, più che una rivoluzione, ed occorre precisarlo sin dall'inizio. Se state cercando qualcosa che sconvolga il vostro modo di fare applicazioni web basate su ASP.NET, non è questo il caso. La versione 2.0 rispetto alla 1.1 ha portato innumerevoli novità. ASP.NET 2.0 ha già la maggior parte delle funzionalità che una buona piattaforma deve offrire, dunque non aspettatevi stravolgimenti.

ASP.NET 3.5 è una versione di passaggio, di consolidamento rispetto alla 2.0 e di unione con le vere novità del .NET Framework 3.5, LINQ in primis.

Struttura ed architettura di ASP.NET 3.5

Dal punto di vista prettamente tecnico, ASP.NET 3.5 è in realtà una serie di funzionalità aggiunte alla versione 2.0, tanto che le vere novità vengono introdotte soprattutto dall'utilizzo del nuovo .NET Framework e dei relativi compilatori per C# 3.0 e VB 9.0.

In estrema sintesi, anche ASP.NET segue il concetto di green bits e red bits, con una serie di funzionalità che sono ereditate dalla versione 2.0 ed un insieme di altre invece introdotte con questa release ed ovviamente non retro compatibili. Per questo motivo un'applicazione scritta per ASP.NET 2.0 può tranquillamente funzionare con la versione 3.5 senza subire cambiamenti.

Dal .NET Framework 3.0 in poi, infatti, il .NET Framework utilizza la versione precedente (tanto che vengono installati dal setup della 3.5 i Service Pack 1 sia della 2.0 che dalla 3.0) aggiungendone e migliorandone il funzionamento, come già riportato nell'articolo introduttivo e riportato per semplicità in questo schema:

Dovendo schematizzare le novità introdotte da ASP.NET 3.5, ecco una lista di ciò che è stato introdotto in questa nuova release:

• nuovi compilatori per C# 3.0 e VB 9.0;
• versione 3.5 di AJAX, direttamente integrata e senza installazioni aggiuntive;
• proxy client per Role API, in aggiunta a Membership e Profile presenti già con ASP.NET AJAX 1.0;
• nuovo assembly System.Web.Extensions, con 3 nuovi controlli (ListView, DataPager e LinqDataSource).

Uno sguardo a VS 2008

Se dovessi fare una mia personale lista di quello che rende ASP.NET 3.5 più interessante rispetto alla 2.0 ci metterei senza dubbio la nuova versione di Visual Studio, disponibile come sempre anche in versione Express, completamente gratuita e scaricabile da MSDN.

Rispetto alla 2005 aggiunge buona parte delle funzionalità disponibili con Expression Web, integrandole direttamente, con un ottimo supporto per i CSS, il markup HTML e le caratteristiche di gestione del design di un sito web, sempre ovviamente dal punto di vista di uno sviluppatore più che di una persona che lavora solo sull'aspetto grafico di un sito.

Rispetto alla versione precedente, VS 2008 offre un ambiente migliorato per la creazione di applicazioni AJAX e Javascript based, con un nuovo motore di debugging misto server-side e client-side, che consente di fare meno fatica durante lo sviluppo di applicazioni che facciano uso di AJAX.

Quello che colpisce maggiormente è ovviamente il tempo di startup, letteralmente diminuito di un decimo rispetto alla versione precedente, condito da una stabilità migliore dell'editor e da una integrazione completa, come è ovvio che sia, con Windows Vista e l'UAC.

Sempre sul fronte dell'editor, prima di passare alla tecnologia vera e propria, spicca la possibilità di utilizzare la cosiddetta "Split View", una modalità di editing nota a chi lavora con WPF, che consente di avere nella stessa finestra sia codice che designer, così da seguire in real time le modifiche fatte nel designer trasformarsi in tag HTML (purtroppo l'operazione inversa necessita di un click per aggiornare la visualizzazione).

Per il resto, VS 2008 introduce un migliore supporto per AJAX e per i control extender, di cui avremo modo di parlare nel resto di questo stesso articolo.

Integrazione con LINQ: LinqDataSource

È fuori di dubbio che la novità più attesa del .NET Framework 3.5 è rappresentata da LINQ e dalle sue potenzialità. Se è vero che LINQ, come è giusto che sia, merita un discorso a parte che viene approndito in questa stessa serie da ben 3 articoli dedicati all'argomento, è utile sottolineare che nasce come progetto del team di ASP.NET, da una effettiva necessità che si ha nelle applicazioni web di rendere quanto più semplice possibile la fase di recupero, filtro e modifica dei dati.

Da questo punto di vista LINQ garantisce una perfetta integrazione con l'ambiente, attraverso l'introduzione di un nuovo controllo di tipo DataSource, specifico per questo scenario, chiamato ovviamente LinqDataSource. A discapito del nome, il controllo non è pensato per lavorare in maniera specifica con LINQ to SQL, ma può essere utilizzato con qualsiasi classe che derivi da DataContext e che abbia al proprio interno l'utilizzo di Table(TEntity). LinqDataSource può lavorare anche con collection e più in generale, a differenza di SqlDataSource, non è pensato per lavorare solo con sorgenti basate su database, offrendosi idealmente come alternativa all'ObjectDataSource.

Inoltre, non è necessario specificare una query di caricamento, modifica, inserimento o cancellazione, perchè sono funzionalità controllare attraverso il DataContext, mentre per modificare quali colonne sono restituite è sufficiente agire sulla proprietà Select, per specificare uno statement LINQ per recuperare gli stessi.

Idealmente dunque sostituisce l'utilizzo del SqlDataSource, che ovviamente rimane a disposizione come alternativa, introducendo però lo stesso tipo di limite: la logica di estrazione viene fortemente accoppiata alla pagina, che non utilizza, come è auspicabile in un'ottica di architettura 3-tier, una serie di classi nella business logic, usando direttamente il DataContext. Questa sarà la scelta preferita da chi predilige l'utilizzo del designer, all'interno del quale è fortemente integrato l'utilizzo di questo nuovo componente, con il tipico wizard di interfacciamento e creazione guidata.

Di buono rispetto a SqlDataSource c'è senza ombra di dubbio la natura meno data-centric di LINQ e di LINQ to SQL, che consente di controllare tutto attraverso il DataContext, agendo sulle politiche di fetching, di validazione e persistenza aggiungendo comportamenti personalizzati che non necessitano poi di intervenire in tutti i punti dell'applicazione in cui si fa uso delle entità di dominio.

Oltre ai consueti DeleteParameters, InsertParameters, UpdateParameters e SelectParameters questo controllo supporta anche la possibilità di specificare parametri attraverso le proprietà GroupByParameters, OrderByParameters e WhereParameters, per influenzare rispettivamente il group by, l'ordine ed impostare un filtro.

<asp:GridView ID="View1" runat="server" DataSourceID="LinqDataSource1" />
<asp:LinqDataSource ID="LinqDataSource1" runat="server"
    ContextTypeName="DataClassesDataContext" EnableDelete="True" 
    EnableInsert="True" EnableUpdate="True" TableName="Authors"
    Where="state == @state">
    <WhereParameters>
        <asp:ControlParameter ControlID="DropDownList1" Name="state" 
             PropertyName="SelectedValue" Type="String" />
    </WhereParameters>
</asp:LinqDataSource>

Resta possibile, ovviamente, utilizzare ObjectDataSource o il databinding manuale qualora si preferisca incapsulare LINQ o LINQ to SQL all'interno di proprie classi, preferendo la scelta di non esporre direttamente il DataContext, ma di usare un wrapper all'interno di una serie di metodi all'interno di una classe.