VBJ n.

77 settembre-ottobre 2005

Architettura di applicazioni gestionali con .NET

di Lorenzo Vandoni
Quale architettura adottare per realizzare unapplicazione gestionale con Visual Studio.NET?

Lorenzo Vandoni ` E laureato in Informati` ca ed e uno specialista di progettazione e sviluppo con tecniche e linguaggi objectoriented in ambiente ` Windows. E direttore del Laboratorio di Ricerca e Sviluppo di Emisfera e coordina un progetto di ricerca internazionale sulle reti wireless, nan` ziato dalla Comunita Europea nellambito del Sesto Programma Quadro (FP6).

pubblicato su WWW.INFOMEDIA.IT stampa digitale da Lulu Enterprises Inc. stores.lulu.com/infomedia

Infomedia
` Infomedia e limpresa editoriale che da quasi venti anni ha raccolto la voce dei programmatori, dei sistemisti, dei professionisti, degli studenti, dei ricercatori e dei professori dinformatica italiani. Sono pi` di 800 gli autori che hanno realizzato per le teu state Computer Programming, Dev, Login, Visual Basic Journal e Java Journal, molte migliaia di articoli tecnici, presentazioni di prodotti, tecnologie, protocolli, strumenti di lavoro, tecniche di sviluppo e semplici trucchi e stratagemmi. Oltre 6 milioni di copie distribuite, trentamila pagine stampate, fanno di questa impresa la pi` grande ed u inuente realt` delleditoria specializzata nel campo della a programmazione e della sistemistica. In tutti questi anni le riviste Infomedia hanno vissuto della passione di quanti vedono nella programmazione non solo la propria professione ma unattivit` vitale e un vero a divertimento. ` Nel 2009, Infomedia e cambiata radicalmente adottando ` un nuovo modello aziendale ed editoriale e si e organizzata attorno ad una idea di Impresa Sociale di Comunit` , a partecipata da programmatori e sistemisti, separando le attivit` di gestione dellinformazione gestite da un board a comunitario professionale e quelle di produzione gesti` te da una impresa strumentale. Questo assetto e in linea con le migliori esperienze internazionali e rende Infomedia ancora di pi` parte della Comunit` nazionale degli u a sviluppatori di software. ` Infomedia e media-partner di manifestazioni ed eventi in ambito informatico, collabora con molti dei pi` imporu tanti editori informatici italiani come partner editoriale e fornitore di servizi di localizzazione in italiano di testi in lingua inglese.

Limpaginazione automatica di questa rivista e realizzata al ` 100% con strumenti Open Source usando OpenOffice, Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp, Python e BASH

For copyright information about the contents of Visual Basic Journal, please see the section Copyright at the end of each article if exists, otherwise ask authors. Infomedia contents is 2005 Infomedia and released as Creative Commons 2.5 BY-NC-ND. Turing Club content is 2005 Turing Club released as Creative Commons 2.5 BY-ND. Le informazioni di copyright sul contenuto di Visual Basic Journal sono riportate nella sezione Copyright alla ne di ciascun articolo o vanno richieste direttamente agli autori. Il contenuto Infomedia e 2005 Infomedia ` e rilasciato con Licenza Creative Commons 2.5 BY-NCND. Il contenuto Turing Club e 2005 Turing Club e ` rilasciato con Licenza Creative Commons 2.5 BY-ND. Si applicano tutte le norme di tutela dei marchi e dei segni distintivi. ` E in ogni caso ammessa la riproduzione parziale o totale dei testi e delle immagini per scopo didattico purch e vengano integralmente citati gli autori e la completa identicazione della testata. Manoscritti e foto originali, anche se non pubblicati, non si restituiscono. Contenuto pubblicitario inferiore al 45%. La biograa dellautore riportata nellarticolo e sul sito www.infomedia.it e di norma quella disponibi` le nella stampa dellarticolo o aggiornata a cura dellautore stesso. Per aggiornarla scrivere a info@infomedia.it o farlo in autonomia allindirizzo http://mags.programmers.net/moduli/biograa

ENTERPRISE

Architettura di applicazioni gestionali con .NET

Quale architettura adottare per realizzare unapplicazione gestionale con Visual Studio.NET?

di Lorenzo Vandoni

In questo articolo viene presentato uno studio che ha lobiettivo di decidere quale architettura adottare per realizzare unapplicazione gestionale di grosse dimensioni, utilizzando Visual Studio.NET. Lo studio prende spunto da un caso concreto, ovvero dalla necessit reale di sviluppare unapplicazione di questo tipo, presenta alcune alternative, ed arriva a proporre alcune scelte ben precise, spiegando perch sono state adottate. Trattandosi di un caso concreto, cominceremo con una discussione dei requisiti di questa applicazione.

Interfacciamento con un database relazionale gi esistente (nel caso specifico, Oracle) Molte maschere con funzionalit di ricerca ed inserimento dati Molti report Lapplicazione dovr essere utilizzata da diverse aziende di grandi dimensioni, e con molte sedi sul territorio nazionale. Per questo motivo, sono particolarmente importanti questi requisiti: facilit di installazione e di aggiornamento efficienza, anche nellaccesso a grandi quantit di dati residenti su database remoti

Requisiti applicativi
L applicazione da realizzare un classico sistema informativo gestionale, che presenta quindi queste caratteristiche principali:
Lorenzo Vandoni, laureato in Informatica ed uno specialista di progettazione e sviluppo con tecniche e linguaggi object-oriented in ambiente Windows. direttore del Laboratorio di Ricerca e Sviluppo di Emisfera e coordina un progetto di ricerca internazionale sulle reti wireless, finanziato dalla Comunit Europea nellambito del Sesto Programma Quadro (FP6). Pu essere contattato allindirizzo lvandoni@infomedia.it

24

VBJ N. 77 - Settembre/Ottobre 2007

ENTERPRISE

L applicazione, di fatto, consiste in un porting di un sistema precedente, realizzato utilizzando Visual Basic 6, Crystal Reports ed Oracle. Per questo motivo, sar anche importante mantenere una sorta di continuit, dal punto di vista funzionale, con la versione precedente. In quella versione, il Figura 1 Architettura client/server classica problema delle installazioni e degli aggiornamenti era stato risolto scegliendo di non installare il programma sul computer degli utenti, ma solo su alcune applicazione client-server di tipo classico macchine, accessibili tramite Terminal Server. Questa soluzione, in parte, permetteva di applicazione web risolvere anche il problema delle prestazioni, in quanto consentiva di applicare le ottimiz applicazione smart client zazioni di tipo sistemistico solo alle macchine server, senza preoccuparsi dei vari client Nei prossimi paragrafi verranno descritte le sparsi sul territorio. caratteristiche principali di ognuna di queste alternative.

Porting su .NET: motivazioni ed alternative

Applicazione client-server classica

Col termine applicazione client-server classica intendo indicare un programma che risiede su una macchina client, e che dialoga tramite SQL con un server di database, come mostrato in Figura 1. In unapplicazione di questo tipo, la logica applicativa risiede quasi totalmente sul client. Al server vengono demandati alcuni controlli, come la duplicazione di chiave primaria o lobbligatoriet dei campi, che per tipicamente vengono implementati anche lato client, e alcune funzionalit database intensive, tipicamente implementate tramite stored procedure. Una soluzione di questo tipo presenta alcuni vantaggi e svantaggi: vantaggio: somiglianza archietturale con la soluzione attuale, con conseguente semVBJ N. 77 - Settembre/Ottobre 2007

La scelta di effettuare il porting su .NET principalmente motivata dalla necessit di slegarsi da un sistema di sviluppo, Visual Basic 6, ormai abbandonato dal produttore. A questa necessit si aggiunge il desiderio di realizzare alcuni miglioramenti strutturali allapplicazione, che non potrebbero essere implementati se non riscrivendola quasi completamente. La scelta di .NET, rispetto ad alternative come Java od altri sistemi, legata a motivazioni di tipo aziendale, come corsi di formazione gi effettuati e certificazioni gi acquisite, per cui non verr ulteriormente approfondita. Scegliendo di utilizzare .NET, le scelte disponibili dal punto di vista architetturale, o almeno quelle che sono state esaminate, sono le seguenti:

25

ENTERPRISE

Figura 2

Architettura semplificata dellapplicazione web

plicit concettuale della fase di porting vantaggio: semplicit architetturale, in quanto buona parte della logica applicativa risiede sul client svantaggio: lapplicazione client diviene particolarmente pesante svantaggio: problemi di installazione e soprattutto di aggiornamento, in quanto diviene necessario installare lapplicazione client sulle macchine di tutti gli utenti

Questa, come gi accennato, anche la soluzione adottata nel sistema attuale, e permette in effetti di semplificare le fasi di installazione e di aggiornamento. I problemi di questa soluzione sono principalmente legati ai costi elevati (delle macchine server) e alla scalabilit limitata (ogni server pu supportare solo un determinato numero di utenti se gli utenti aumentano necessario installare nuovi server).

Applicazione web
La seconda possibilit che stata considerata quella di creare unapplicazione web, la cui architettura semplificata mostrata in Figura 2. In questo caso il programma costituito da un insieme di pagine ASP .NET, che risiedono sul server web, e che comunicano tramite SQL col server di database. La comunicazione con il client avviene tramite http, e il programma pu essere utilizzato tramite un web browser. Sul browser, oltre al codice HTML che costituisce linterfaccia grafica del programma, pu essere eseguito del codice Javascript. In un programma di questo tipo, la logica applicativa risiede quasi totalmente sul server, ed implementata dalle pagine ASP .NET. Al server di database possono essere demandati gli stessi controlli e le stesse funzionalit menzionati al punto precedente, men-

Lapplicazione da realizzare un classico sistema informativo gestionale

Una possibile variante, per ovviare a questultimo problema, potrebbe essere quella di utilizzare Terminal Server. In questo modo, lapplicazione non verrebbe installata direttamente sulle macchine degli utenti, ma su un numero limitato di server, ai quali le macchine client potrebbero accedere come semplici terminali.

26

VBJ N. 77 - Settembre/Ottobre 2007

ENTERPRISE

Figura 3

Architettura della soluzione smart client

tre sul client possono essere implementati, in Javascript, alcuni controlli e funzionalit elementari. Per una soluzione di questo tipo, vantaggi e svantaggi sono i seguenti: vantaggio: problemi di installazione e di aggiornamento molto limitati, e quasi esclusivamente costituiti dalla necessit di verificare la compatibilit coi vari browser web disponibili svantaggio: larchitettura diviene pi complessa, alcuni controlli (es. obbligatoriet di campi) potrebbero essere implementati in ciascuno dei tre livelli svantaggio: lo sviluppo web presenta difficolt di implementazione oggettivamente superiori, legate soprattutto al fatto che il web non nato per ospitare applicazioni di questo tipo svantaggio: le applicazioni web sono necessariamente pi limitate, nellinterfaccia grafica, e consentono una minore interattivit con lutente Alcune di queste limitazioni potrebbero essere superate adottando delle tecniche/

Lapplicazione dovr essere utilizzata da diverse aziende di grandi dimensioni

tecnologie Ajax, cio facendo in modo che la pagina web residente sul client possa comunicare con il server e aggiornare il proprio contenuto. In questo caso, si otterrebbe una soluzione simile a quella discussa nel paragrafo successivo, ma basata su web.

Smart client
Uno smart client unapplicazione client di livello intermedio rispetto alle due precedentemente esaminate. pi leggera di unapplicazione client-server di tipo classico, ma pi intelligente rispetto a una normale applicazione web. Uno smart client pu essere realizzato sia come applicazione Windows, sia come applicazione web, utilizzando Ajax. La sua architettura mostrata in Figura 3. VBJ N. 77 - Settembre/Ottobre 2007

27

ENTERPRISE

In questo caso il programma client costituito da una classica applicazione Windows, che per demanda una gran parte della logica applicativa a uno strato software residente sul web server, implementato tramite Web Service. La comunicazione tra smart client e programma server avviene tramite http, mentre questultimo usa SQL per interagire con il database. In un programma di questo tipo la logica applicativa suddivisa tra i tre livelli. Rispetto alla soluzione precedente, il client pi intelligente (smart, appunto), e potr eseguire un maggior numero di controlli. Tipicamente, sul client verranno implementati controlli e funzionalit che possono essere gestiti utilizzando solo i dati precedentemente inviati dal server, senza accedere nuovamente al database. In questo caso, i principali vantaggi e svantaggi sono: vantaggio: problemi di installazione e di aggiornamento relativamente limitati vantaggio: semplicit di sviluppo, senza le complicazioni tipiche delle applicazioni web vantaggio: maggiori potenzialit nel disegno dellinterfaccia grafica svantaggio: larchitettura diviene molto pi complessa Un caso particolare di smart client, come precedentemente accennato, potrebbe essere costituito da unapplicazione web che, grazie allutilizzo di Ajax, sia in grado di portare sul client un maggior numero di funzionalit. Una soluzione di questo tipo potrebbe essere sicuramente interessante per lo sviluppo di unapplicazione Internet, ma nel nostro caso si rivela poco interessante, perch porterebbe con s tutti gli svantaggi delle ultime due soluzioni esaminate (complessit architetturale e complessit implementativa, soprattutto), senza apportare vantaggi significativi.

Quale soluzione scegliere

Una volta esaminati vantaggi e svantaggi legati alle varie soluzioni esaminate, la scelta ricaduta su unapplicazione di tipo smart client. In particolare, sulla decisione hanno pesato la necessit di stratificare lapplicazione per rendere meno pesante il programma client, e la complessit intrinseca lagata allo sviluppo di applicazioni gestionali in ambiente web. Tale complessit avrebbe introdotto difficolt sicuramente superabili, ma in grado di rallentare sensibilmente il processo di sviluppo. Un ulteriore elemento a favore della soluzione smart client, reso evidente dai test sui primi prototipi, legato alla maggiore velocit dellapplicazione, rispetto ad unanaloga applicazione web. Il passaggio da una maschera ad unaltra, in particolare, risulta estremamente pi veloce, in quanto tutti gli elementi di interfaccia grafica sono gi presenti sul client. In questo modo, lutente ha la percezione di lavorare su unapplicazione remota, ma allo stesso tempo ottiene la maggior parte dei benefici legati ad un programma che funziona localmente.

Altre caratteristiche dello smart client

Abbiamo finora esaminato solo le caratteristiche pi generali dellarchitettura proposta. Per concludere larticolo, vengono qui elencate altre caratteristiche del tipo di architettura che stata successivamente realizzata: Installazione di tipo ClickOnce. Si tratta di un utile automatismo fornito con Visual Studio 2005, che permette la pubblicazione di unapplicazione su un sito web, e la conseguente gestione automatica di installazioni ed aggiornamenti. L adozione di questa tecnologia permette di risolvere gran parte dei problemi legati al deployment. Realizzazione di codice di libreria, lato server e lato client. Lo sviluppo dellapplicazione stato preceduto dalla realizzazione di alcune funzionalit di base, che risultano comuni ai vari moduli. Lato client, sono

28

VBJ N. 77 - Settembre/Ottobre 2007

ENTERPRISE

stati realizzati o, in alcuni casi, adottati, tutti i componenti di interfaccia necessari per realizzare unapplicazione gestionale di livello professionale: griglie, finestre di ricerca, campi di lookup, ecc. Sono state inoltre realizzate delle classi base per incapsulare tutti i comportamenti comuni alle finestre dellapplicazione client. Lato server, sono state realizzate delle classi base per i Web Service. Gestione di profili in formato XML. La maggior parte delle caratteristiche applicative (campi di ricerca, colonne da visualizzare, relazioni tra le tabelle, regole di validazione, ecc.) sono state specificate allinterno di file di profilo, in formato XML, residenti sul server. Per ogni funzionalit (es. gestione clienti) sono state create una o pi form sul programma client (ClientiFrm.vb), un solo Web Service (ClientiWS.vb) e un solo file di profilo (Clienti.XML). Il file XML risiede sul server, ma contiene informazioni che riguardano anche linterfaccia grafica. Per questo

motivo viene spedito dal server al client, che lo riceve come stringa, gestendolo interamente in memoria. L uso combinato di codice di libreria e profili XML ha permesso di creare unapplicazione estremamente versatile, in cui il codice applicativo relativamente limitato. In particolare, grazie alla gestione lato server dei profili, possibile modificare diverse caratteristiche applicative senza ricompilare lapplicazione n installare aggiornamenti presso il cliente.

Conclusioni
In questo articolo stato descritto il processo decisionale che ha portato alla scelta di una particolare architettura per la realizzazione di una complessa applicazione gestionale con Visual Studio.NET. Le considerazioni fatte in questo contesto possono essere applicate in molti altri casi analoghi, anche se ovviamente non possono avere una valenza di tipo generale.

VBJ N. 77 - Settembre/Ottobre 2007

29