Con Visual Basic 6.0 Microsoft ha introdotto un nuovo tipo di progetto, denominato "Applicazione IIS", meglio conosciuto come Webclass. Scopriamo con una breve panoramica di cosa si tratta, che caratteristiche ha, quali vantaggi e svantaggi presenta rispetto alle tradizionali ASP.

A cosa servono

Per prima cosa diciamo subito a cosa servono le Webclass: servono a realizzare applicazioni ad interfaccia Web.

Portano quindi a un risultato molto simile a quanto già viene fatto con le ASP, ma questo viene raggiunto con soluzioni completamente diverse, sia dal punto di vista tecnologico che operativo. Le due tecnologie non vanno perciò confuse, anche perché, come vedremo, l'una non esclude l'altra e spesso le si possono utilizzare entrambe. Entrando poi nei dettagli tecnici vedremo che il legame fra le due realtà è strettissimo, al punto che senza l'una, l'altra non avrebbe motivo di esistere.

Cosa sono

Dal punto di vista tecnologico le Webclass sono delle componenti ActiveX ospitate all'interno di Information Server. Si tratta quindi di frammenti di codice compilato, che vengono richiamati dal server in corrispondenza di determinati eventi. E, in effetti, le WebClass sono nate per riportare su Web il modello di sviluppo ad eventi di Windows, in modo da facilitare la realizzazione di soluzioni ad interfaccia Web da parte di tutti i "tradizionali" sviluppatori Visual Basic. Pertanto, come vedremo, tutta la logica di funzionamento delle Webclass è basata sulla programmazione ad eventi.

Questo non significa che sia una tecnologia d esclusivo appannaggio degli sviluppatori Visual Basic. Chi, come il sottoscritto, viene direttamente dal mondo Web e della programmazione con ASP, non avrà comunque grossi problemi a comprenderne le logiche.

La struttura di un progetto Webclass

Un progetto WebClass è strutturato al suo interno in diverse Webclass. Da questo punto di vista, una Webclass è un'unità logica a sé stante, che si occupa di una serie di operazioni concettualmente riunite. Ad esempio, può trattarsi di tutte le pagine di ricerca e visualizzazione dei dati di un database. Oppure di tutte le pagine relative all'iscrizione o gestione del proprio profilo all'interno di una mailing list.

Ciascuna di queste pagine è chiamata Webitem, proprio perché si tratta di un elemento dell'applicazione Web.

Ad ogni Webitem sono associati degli eventi. Per capire il perché, pensiamo al modello Windows. Ogni applicazione (progetto Webclass) è strutturata in maschere (WebClass), ciascuna delle quali ha diversi controlli (Webitem). Ogni controllo ha diversi eventi, ad esempio quello di click o di doppio click. Così ogni Webitem ha diversi eventi, come, ad esempio, quello di chiamata generica della pagina (ricordiamoci sempre che, dal punto di vista dell'utente, un Webitem è una pagina).

Il lavoro dello sviluppatore consiste nella strutturazione della propria applicazione per capire quali WebClass utilizzare, quali Webitem per ciascuna di essa, e quali eventi rendere disponibili. Ovviamente, come ultimo passo, bisogna poi scrivere il codice per gestire correttamente questi eventi.

Quali differenze con ASP

Innanzitutto una differenza immediata e banale: le ASP sono un linguaggio di scripting, inserito nelle pagine HTML ed interpretato al volo da Information Server. Le Webclass, al contrario, sono un particolare utilizzo di Visual Basic. Pertanto utilizzano un linguaggio completo e maturo, e danno luogo a codice compilato (una dll per intenderci).

Quindi con Webclass si ha a disposizione Visual Basic e non Viasual Basic Script, che non sono proprio la stessa cosa, anche se agli utilizzatori più "leggeri" potrebbero sembrarlo.

Il lavorare all'interno di Visual Basic consente poi una maggiore flessibilità nell'uso-scrittura-integrazione di componenti esterne per l'implementazione della logica del sito. Ovviamente questo vale anche per la realizzione strutturata di un progetto a componenti, anche se le componenti le scriviamo tutte noi e non attingiamo a quelli degli altri. I benefici sono comunque altissimi rispetto ad ASP.

Inoltre, come in tutti gli ambienti, un codice compilato ha prestazioni superiori rispetto a una codice interpretato. Pertanto le Webclass risultano nettamente più veloci di una pagina ASP. Attenzione però, questa differenza non si nota in applicazioni piccole e leggere, dove l'overhead delle chiamate alle dll si fa sentire ed invece l'interprete di IIS è ottimizzato. Si fa sentire sui siti ad alto traffico e soprattutto in quelli che implementano operazioni complesse.

Poi c'è una differenza radicale relativa all'impostazione e all'approccio al progetto. In ASP il codice VB e quello HTML sono mischiati l'uno con l'altro. Questo, a parte il rischio della grossa confusione che può generare in pagine complesse e male organizzate, comporta un approccio al lavoro di gruppo che prevede il contemporaneo utilizzo degli stessi file da parte del programmatore ASP e del grafico o comunque di colui che si preoccupa dell'aspetto HTML del sito. Questo non è un problema quando le due figure sono la stessa persona, ma in un contesto di team si fa sentire, anche se utilizzate amenità quali gli ambienti di sviluppo condiviso legati a Frontpage, che comunque sono applicabili con reali benefici sono in un contesto di LAN. Con Webclass è possibile separare i due compiti, facendo scrivere e modificare in libertà il codice VB al programmatore, e nel contempo dando in mano con piena libertà i modelli html al grafico. Possibilità molto gradita e produttiva soprattutto in fase di revisione, ottimizzazione e debugging di un sito appena realizzato.

Ma i problemi dove sono?

In realtà Webclass non è una specie di evoluzione di ASP, che quindi ne supera le possibilità mantendone il meglio. Webclass nasce, seppur basandosi indubbiamente sull'esperienza di ASP, da una filosofia e una storia completamente diverse. Quindi introduce dei problemi che ASP non ha.

Il principale, su cui ci soffermiamo, è quello dell'installazione e distribuzione. Installare e distribuire un prodotto ASP è facile e rapido: si caricano in FTP i sorgenti sul server e il gioco è fatto, a meno delle impostazioni di base da fare, scontate per un corretto funzionamento.

Con Webclass non è affatto così semplice. Trattandosi infatti di componenti di codice, di DLL, il nostro server NT prevede un trattamento più complicato: dobbiamo infatti trovare il modo di installare correttamente le dll generate dal compilatore.

La prima strada, da seguire solo nella prima installazione, è quella di utilizzare il Package & Deployment wizard di VB. Tale strumento realizza un setup completo delle componenti necessarie a far girare il nostro sito. Dicevo che se ne consiglia l'utilizzo alla prima installazione, perché così si è sicuri di mettere e registrare correttamente anche i componenti di run-time.

Per i successivi aggiornamenti non è in realtà necessario ricorrere a un setup vero e proprio. La procedura più semplice è probabilmente quella di far rilasciare a IIS i riferimenti alla dll da aggiornare, sovrascriverla con quella nuova e registrarla manualmente. In questo modo si aggiorna tutto il sito, comunque in un minuto o due al massimo. Certo, non è così comodo come un upload FTP, anche se ci sarebbe un sistema per cavarsela in ftp, ma prevede lo stop remoto di IIS. Però non è neanche la fine del mondo, a patto che si abbia accesso al server o che ci lavori qualcuno che dà ascolto alle nostre richieste (come detto gli si chiedono due minuti al massimo per l'aggiornamento).

Un secondo problema è quello dell'assoluta mancanza di materiale informativo e di training (si trova solo qualcosa nella guida di VB e su qualche sito MS). Ma non è così grave, considerando che, anche per ASP, all'inizio non c'era niente.

Conclusioni

Webclass è una tecnologia nuova nell'approccio allo sviluppo di siti Web dinamici in ambiente IIS. L'esperienza dalla quale sono tratte queste considerazioni (quasi un anno di progetti in uso sul campo) consente di dire che le Webclass sono uno strumento potente ed importante nel panorama di quanto deve avere a disposizione uno sviluppatore di soluzioni Web dinamiche. Bisogna però capire bene in quali contesti utilizzarle.

Ad esempio, una soluzione ottimale è quella di realizzare siti parte in Webclass e parte in ASP: in questo modo è possibile inserire tutte le parti più dinamiche in Webclass, con tutti i vantaggi del caso, e le parti più statiche e testuali in normali ASP. Il tutto, ovviamente, facendo comunicare le due anime del sito e non duplicando nessuna funzionalità. Ad esempio, facendo generare tutti gli elementi comuni (e che magari richiedono un po' di calcoli per essere determinati) dalla Webclass (richiamandone i metodi dalla nostra pagina ASP come per un normalissimo componente), e facendo scambiare correttamente i dati delle operazioni fra ASP e Webclass (ci sono molti modi per farlo) in modo da creare una sessione utente trasparente al passaggio da pagine ASP a pagine Webclasss, e viceversa.