Indice
Introduzione...2
Cosa è un Web Journal...4
Il Software realizzato: caratteristiche e problematiche introdotte...6
Parte Prima...15
Architettura a 3 Livelli...15
Architettura di una Applicazione Web...27
.NET - LINQ e Studio Delle Performance ...39
Parte Seconda...48
Il FrameWork. ...48
Features 1:WorkFlow Per Gli Articoli...80
Features 2:Gestione dei Menu...88
Feature 3: Progettazione e realizzazione delle Rubriche...96
Features 4: Gestione dei Tag Associabili ad un articolo...105
Monitoraggio delle Prestazioni dell'applicazione e prime ottimizzazioni ...108
Ulteriori Ottimizzazioni effettuate sul DB...120
Conclusioni e Sviluppi futuri...126
Le frasi celebri dei Programmatori e Dei Clienti...128
Bibliografia...131
Introduzione.
“Una soluzione complessa ad un problema non è necessariamente la soluzoine Migliore per tale problema”
La tesi che ho svolto ha riguardato la realizzazione di Framework per lo sviluppo, gestione e visualizzazione dei contenuti informativi dei Web-Journal: è inoltre stata un esperienza lavorativa completa e retribuita nell'ambito della reingegnerizazione e realizzazione di applicazioni per riviste e Quotidiani Online svolta presso la Software-House Bitflow.
Allo stato attuale dell'arte, il Framework implementato è alla versione 2.5 e verrà utilizzato a partire dal 20 Gennaio 2009 in altri progetti presso Bitflow.
Il punto di partenza è stato un vecchio software ereditato da un azienda che ha abbandonato tale progetto; a partire da tale applicativo e dalle commissioni richieste da un cliente è stato realizzato non solo il software ma anche il Framework, nella visione di poter appunto riutilizzare il codice prodotto in un futuro recente.
Le Parti fondamentali del lavoro svolto, hanno riguardato lo studio e l'analisi(Globale/Nel Dettaglio) della realtà d'interesse attraverso l'utilizzo del sistema esistente, delle sue funzionalità. E dunque stata necessaria l'interazione con il cliente; Tale analisi ha permesso di capire le inefficienze in termini di usabilità del sistema stesso; All'interno di tale fase si colloca anche la fase di analisi del codice esistente; si è cercato di capire come il sistema realizzava le operazioni e le funzionalità e ciò ha permesso di capire sia gli errori presenti che le limitazioni in termini di prestazioni del sistema stesso;
come descritto più nel dettaglio nei capitoli successivi, tali limitazioni sono dovute oltre che all'utilizzo di una piattaforma HW/SW ormai obsoleta, anche alla totale mancanza di progettazione sia della Base Dati che dell'Applicazione;
Un ulteriore limite era da ricercarsi nel fatto che il codice era stato sviluppato senza utilizzare le API del .NET Framework e rivelandosi di fatto una semplice estensione della Tecnologia ASP;
In pratica tutto il livello di Presentazione è stato implementato iniettando codice html piu stili CSS prodotto dinamicamente, senza fare uso alcuno di controlli ASP.NET; mentre l'interfaccia verso i dati è stata implementata usando I Dataset Tipizzati; struttura che si rivela oggi obsoleta, pesante in termini di righe di codice da analizzare e di prestazioni, e di difficile modifica; Il Database invece ha rilevato inefficienze tali da bloccare l'applicazione dopo il primo rilascio; durante la fase di entrata a regime dell'applicazione.
L'applicazione si è appoggiata in una prima fase su una piattaforma hardware/software vecchia di dieci anni (WINDOWS SERVER 2000 privo di aggiornamenti e SQL SERVER 2000) e quindi del tutto
inadeguata alle esigenze di un sistema come quello attuale (15000 utenti al giorno e 11.000 articoli da gestire);
Il modo di procedere ha seguito le linee guida previste dalla Programmazione Agile e dell'Extreme Programming; tale modo di procedere è stato dettato dalle tempistiche stringenti per il rilascio e l'aggiornamento del software, e ha consentito la realizzazione di un software quanto più vicino alle richieste del cliente; Per tutte quelle funzionalità invece che hanno presentato tempi di realizzazione troppo lunghi(Tempi di realizzazione ipoteticamente superiori ai 15 giorni) si è passati ad una progettazione e a uno studio più accurato, e a discussioni di gruppo per cercare di capire le tempistiche di realizzazione e quindi in quali fasce temporali localizzarle, congiuntamente alle priorità del cliente e alla criticità della funzionalità aggiunta;
il monitoraggio continuo del sistema che via via si rilasciava ha permesso di individuare prontamente i limiti e le problematiche bloccanti per il sistema; problematiche che sono state risolte anche attraverso il miglioramento della Base Dati, la sua ottimizzazione attraverso strumenti automatici o agendo direttamente sulle operazioni; sono state studiate diverse tecnologie da utilizzare nell'applicazione ed è stato svolto un lavoro parallelo in modo tale da non sperimentare direttamente sul software che si metteva in produzione le nuove tecnologie e le nuove funzionalità ma, dopo un periodo di test , in cui si controllava sia il processo di integrazione delle nuove funzionalità introdotte che la correttezza, affidabilità del software; solo dopo si è effettuato il rilascio; questo modo di procedere anche se presenta delle tempistiche leggermente più lunghe permette di avere una conoscenza molto maggiore e sopratutto una robustezza maggiore; tale realizzazione è stata resa possibile attraverso semplici ambienti di simulazione remoti e locali che riproducevano il sistema che si rilasciava al cliente.
Le tecnologie usate sono state Asp.net AJAX 2.0 e Successivamente Asp.net 3.5 più altre funzionalità introdotte con il .Net Framework 3.5 quali LinQtoSQL e EF anche se la difficoltà maggiore è stata la realizzazione del Porting in Asp.net 2.0. Le piattaforme su cui si è fatto il Porting sono state WINDOWS SERVER 2003 R2 e SQL SERVER 2005; si è dovuto optare per queste soluzioni a seguito di una un accurata analisi insieme al committente anche se è stato già ipotizzato un Porting alla versione 2008 di SQL SERVER e WINDOWS SERVER. Come introdotto precedentemente lo studio e la realizzazione delle funzionalità non si è limitato alla messa in produzione del software ma alla realizzazione di un FrameWork riutilizzabile, ottimizzato; si è dovuta dunque pensare un architettura di base in cui implementare tutte le funzionalità. Ci si è dunque basati su un architettura a 3 Livelli e 2 Strati (3-Layers 3-Tiers), ovvero la progettazione del software si è basata sul modello
“Presentation-Business-DataAccess” Layer, mentre per quanto riguarda la struttura Hardware ci si è basati sul modello a tre strati (“Client-Tier”,”Web-Tier”,”DataBase-Tier ”).
Fig.1. Architettura a Tre Livelli.
Fig.2. Modello di sviluppo a 3 Livelli e 3 stati.
Cosa è un Web Journal.
Un Web Journal è una Applicazione Web utilizzata per visualizzare e gestire articoli. Le problematiche principali che si incontrano nella realizzazione di tale tipologia di applicazione sono la forte dinamicità dei contenuti informativi che possono cambiare in intervalli temporali molto brevi, più il bisogno di gestire grosse quantità di informazioni ricadendo in problematiche di performance. Un altro problema è legato al numero di utenti che possono visitare tale applicazione che può compromettere le prestazioni del sito.
E' dunque necessario realizzare un Framework che permetta la gestione automatizzata e ottimizzata del flusso di informazioni e dia la possibilità di organizzare le informazioni in modo tale da gestire le più svariate tipologie di articoli, il tutto rispettando requisiti in termini di prestazioni molto stringenti.
Il FrameWork realizzato con tecnologia .NET è stato utilizzato per realizzare un WebJournal in cui i vincoli sopracitati erano fortemente critici:
• 20000 utenti al giorno con media di 7 minuti circa di permanenza sul sito
• Picchi di 1000 utenti connessi contemporaneamente per pochi minuti
• 10000/20000 articoli da gestire con media di 30-60 articoli pubblicati ogni giorno
• Circa 30000 pagine visitate più di Milione di volte
• Ogni pagina del sito è stata visualizzata almeno una volta, dato importane se si considera la complessità dell'applicazione
Il Software realizzato: caratteristiche e problematiche introdotte.
In questa sezione descriverò con rigore gli scopi e le funzionalità del software al fine di descrivere con precisione la realtà d'interesse e ciò che stato realizzato. Un ampio spazio verrà dedicato alle problematiche iniziali che si sono incontrate e che hanno condizionato il ciclo di vita del software.
Il software sviluppato ha riguardato la realizzazione di un FrameWork poi applicato ad un Web Journal, Lo scopo di un WebJournal è la sostituzione completa e in formato digitale del vecchio giornale, nel nostro caso particolare la sua funzione è quella di essere un degno sostituto del vecchio Quotidiano. Uno dei tanti vantaggi dei Quotidiani Online è la possibilità di mantenere contenuti informativi aggiornati e attuali in tempo reale.
Il software che ha realizzato il Quotidiano Online è composto da due applicazioni:
• La prima(che chiameremo per comodità Site) si occupa della presentazione degli articoli approvati e pubblicati dalla redazione della testata giornalistica;
• La seconda applicazione(che chiameremo Admin) gestisce tutto il sito di presentazione, dunque gli articoli, gli utenti, gli spazi pubblicitari ecc...
La scelta nell'utilizzo e lo sviluppo di due applicazioni invece che una è stata dettata dal fatto che il codice sviluppato è stato in minima parte ereditato da un altra azienda. Sotto sono elencate le funzionalità sviluppate per il cliente sia Lato Site che lato Admin
Lato Site
Funzionalità Descrizione
Visualizzazione personalizzata degli articoli Gli articoli possono essere visualizzati in base al canale tematico cui fanno parte, in base alla loro posizione nelle pagine principali del sito(Home Page), in base alla data di pubblicazione in base alla rubrica di appartenenza, o gruppo di appartenenza Visualizzazione di rubriche tematiche E' possibile visualizzare le rubriche del
Quotidiano OnLine con annessi gli articoli relativi
Visualizzazione spazi pubblicitari Possibilità lato site di avere una visualizzazione personalizzata nelle varie pagine del Sito (Lato Site) dei banner pubblicitari
Visualizzazione articoli nuovi e mai letti Possibilità per un utente loggato al sito di distinguere tra articoli mai letti e articoli letti Visualizzazione degli autori e intervistati Possibilità per un utente qualunque di vedere
la lista degli intervistati e autori
Visualizzazione Feed Possibilità per un utente Qualunque di visualizzare i Feed-RSS associati ai canali tematici e agli articoli
Ricerche di articoli all'interno del sito Possibilità di effettuare ricerche personalizzate sul contenuto degli articoli del Giornale OnLine
Invio articoli Possibilità per un utente loggato di segnalare un articolo ad un amico inserendo l'indirizzo mail
Invio messaggi Possibilità per un utente loggato di inviare
messaggi agli autori del sito e ottenere risposta
Lato Site
Funzionalità Descrizione
Commentare articoli Possibilità di commentare articoli da parte degli utenti loggati e ottenere una risposta da parte dell'autore dell'articolo
Visualizzare i commenti all'articolo Possibilità per tutti gli utenti di visualizzare i commenti dell'articolo
Visualizzazione articoli più letti commentati Possibilità per tutti gli di vedere gli articoli più letti e più commentati del giornale
Possibilità di visualizzare sondaggi Un utente può partecipare a dei sondaggi realizzati dalla redazione della rivista e pubblicati Lato Site
Personalizzazione HomePage Possibilità per un utente loggato di personalizzare la propria HomePage scegliendo gli articoli degli autori preferiti e dei canali tematici preferiti
Visualizzazione Video Possibilità per tutti gli utenti di vedere video Visualizzazione video di appositi corsi Possibilità per utenti loggati e autorizzati di
vedere appositi video formativi su determinati argomenti
Visualizzazione meteo e canali musicali Possibilità per tutti gli utenti di accedere a servizi sulle previsioni meteo e ascoltare canali musicali impostati dagli amministratori del sito
Realizzazione di un sistema di Tagging per Articoli
Possibilità di visualizzare per ogni articolo i Tag che vorrebbero classificarlo
Lato Admin
Funzionalità Descrizione
Visualizzazione Articoli Possibilità per amministratori e redattori di visualizzare in base alla sezione e al canale tematico, tutti gli articoli, approvati e non Gestione Articoli Possibilità per gli amministratori di gestire
l'ordine di pubblicazione degli articoli e le ore i giorni in cui pubblicare tali articoli, la gestione della pubblicazione degli articoli è in oltre automatizzata ovvero gestita in modo automatico dalla applicazione
Gestione Risorse Possibilità di caricare nel sito immagini, file in formato Pdf sia per i redattori che per gli amministratori
Gestione Articolo Possibilità di creare cancellare
approvare(Solo per Attori Amministratori), modificare, pubblicare un articolo aggiungendo immagini file e collegamenti allegati, e gestendo attraverso apposito editor(FckEditor aggiornato all'ultima versione ) il contenuto testuale
Gestione commenti Possibilità di convalidare, cancellare e inserire risposte ai vari commenti scritti dai lettori agli articoli della rivista(Solo per Amministratori)
Gestione Canali tematici e sezioni tematiche Possibilità per gli amministratori di creare cancellare approvare canali e sezioni tematiche, ovvero canali e sezioni contenenti articoli
Gestione Gruppi di articoli Possibilità di creare, cancellare gruppi di articoli e associare più articoli ad ogni gruppo, o cancellare articoli facenti parte di un gruppo(solo per Amministratori)
Lato Admin
Funzionalità Descrizione
Gestione Rubriche Possibilità di creare modificare le rubriche tematiche(solo per Amministratori)
Gestione Autori Possibilità di creare cancellare modificare autori e intervistati della rivista più la possibilità di approvare e dunque inviare messaggi dei lettori agli autori(solo per Amministratori)
Gestione spazi pubblicitari Possibilità di visualizzare e associare ad ogni pagina contenuto informativo pubblicitario personalizzato con i rispettivi formati grafici(solo per Amministratori)
Gestione TV online Possibilità di aggiungere approvare e eliminare video che verranno poi visualizzati Lato Site nell'apposita pagina(solo per Amministratori)
Gestione Account Possibilità di creare approvare eliminare gli account dei lettori più la possibilità di effettuare ricerche per account(solo per Amministratori)
Gestione Corsi Possibilità di aggiungere dei video corsi e permettere la visualizzazione degli stessi in fasce temporali assegnabili; possibilità di associare dei lettori a tali video di modo tale che nei periodi di proiezione di tali video solo tali utenti possano vederli (solo per Amministratori)
Le funzionalità sopra elencate mostrano la necessità di definire gli attori principali che utilizzano il software;
Attori
Attore Descrizione
Utente Anonimo Utente non autenticato, che può visitare il sito Lato Site
Utente Autenticato Utente registrato e autenticato al Sito Lato Site, può inviare messaggi agli autori condividere e segnalare articoli ad amici,commentare gli articoli, impostare le proprie preferenze nella scelta dei canali tematici preferiti, e autori preferiti, possibilità di leggere articoli nuovi e mai letti Utente Autenticato ai Corsi Utente Autenticato che ha la possibilità di
accedere alle pagine dei video corsi
Redattore Utente che accede al Lato Admin della
applicazione e può scrivere e modificare articoli caricare immagini ma non può approvarli
Amministratore Colui che amministra il sito Lato Admin, gestisce banner e approva articoli ecc... Può accedere ad entrambe le Applicazioni.
Descrizione stato iniziale e problematiche inerenti lo sviluppo del software
La seguente sezione descrive quali sono le problematiche iniziali che si sono incontrate nello sviluppo del software, tali da condizionare il modo di procedere nell'analisi, riprogettazione,e realizzazione dell'applicazione.
Come primo punto va sottolineato il fatto che non si è realizzato il software partendo esclusivamente dalle specifiche, ma il progetto e il codice, è stato ereditato da un altra azienda che ne ha abbandonato lo sviluppo; questo ha portato qualche vantaggio e tantissimi svantaggi; il software allo stato iniziale si è presentato:
• Incompleto(sotto è presente lo schema iniziale del DB privo di tutte le ottimizzazioni),
• nelle poche funzionalità implementate il software ereditato si è rivelato
• obsoleto,
• con prestazioni inefficienti,
• di difficile comprensione,
• ricco di errori e dunque mai testato,
• Privo di documentazione;
IL vantaggio principale invece è stato quello di avere una base di partenza su cui riprogettare tutto e uno scheletro dell'applicazione già implementato secondo alcune specifiche richieste dal cliente. Queste problematiche hanno influenzato molto lo sviluppo successivo, i ritardi nello sviluppo precedentemente realizzato, hanno portato inoltre il cliente a delle richieste di cambiamenti dettate dal fatto che alcune funzionalità essendo ora obsolete andavano modificate; In conseguenza di ciò si è optato per una modalità di realizzazione del software tale da permettere al cliente di vedere e testare le funzionalità del programma man mano che si sviluppavano. In una realtà di sviluppo software in cui un cliente abbia l'esigenza di seguire il processo di sviluppo e abbia l'esigenza di vedere i risultati per quanto parziali in tempi brevi, una soluzione da tenere in considerazione è dunque quella offerta dalla Programmazione Agile. Il problema principale affrontato in tale contesto è stato quello di sviluppare, correggere il software senza commettere nuovi errori che compromettessero la correttezza delle funzionalità sviluppate nelle sotto-versioni precedenti e dunque portassero il software in uno stato inconsistente. Questo modo di procedere è stato dettato da tempi brevi a disposizione per conoscere il software, dal livello di complessità del software, da una precedente mala-progettazione e dalle richieste del committente.
I due principali punti di partenza sono stati dunque lo Schema della Base di Dati iniziale sotto
riportato, più le funzionalità del software realizzate in precedenza in particolare:
• L'interfaccia grafica dell'applicazione lato Site già realizzata (successivamente ricostruita secondo una veste Grafica nuova, ottimizzata e realizzata con tecnologie più attuali);
• Le altre funzionalità già presenti, utilizzate per conoscere il software sono state :
• la Visualizzazione degli articoli,
• la Gestione degli Account,
• la Gestione degli Autori,
tali funzionalità facevano parte dell'applicazione Admin;
Sotto è riportato lo schema iniziale della Base Dati al 20 febbraio 2008 data di partenza dei lavori
Figura 8. DB iniziale al Mese di Febbraio 2008
Parte Prima.
“Risulta che i vocaboli della Matematica, e in generale di ogni scienza sono internazionali, cioè comuni alle lingue europee, dall'italiano all'inglese, dallo spagnolo al russo”
Giuseppe Peano
Architettura a 3 Livelli.
Questa sezione è dedicata alla descrizione dell'architettura a 3 Livelli delle applicazioni software come descritto in [240]. Tale descrizione raggruppa i vari componenti del software in Livelli(Layer) separati o Strati(Tiers) in grado di comunicare gli uni con gli altri. I livelli sono pensati come suddivisione logica dei componenti, senza tener conto della loro collocazione fisica nei vari server o netwoks. Gli Strati sono concepiti come suddivisione dei componenti software sui servers, computer, networks, ecc.. Si può dunque pensare al termine
“Tiers”, come se si riferisse alla distribuzione fisica dei componenti software sulle varie macchine.
I Livelli(Layers).
Per livello si intende il raggruppamento dei componenti software che realizzano l'applicazione. I livelli mettono in evidenza e classificano i componenti software sulla base delle operazioni che svolgono, facilitando la creazione dei componenti. Ogni livello logico contiene componenti, ed è suddiviso in ulteriori sottolivelli(SubLayer) ognuno dei quali esegue una determinata operazione. Suddividere l'applicazione in livelli distinti, disgiunti e in comunicazione tra loro permette di massimizzare il processo di mantenimento del codice, di capire in quali strati(Tiers) sviluppare certi livelli(Layers) piuttosto che in altri e con quali componenti, quali decisioni di progettazione prendere in quali livelli e quali strati.
Generalmente un architettura come quella sopra citata è costituita da 3 Livelli: il livello di Presentazione, il livello di Business, e il livello per l'accesso ai dati e per il recupero delle informazioni.
• Livello di Presentazione. Fornisce i servizi per l'interazione dell'utente con il sistema.
Può essere considerato il ponte verso il “Core” del Livello di Business
• Livello Business. Implementa le funzionalità base del sistema
• DataAccess Layer . Si occupa di estrarre i dati richiesti e passarli attraverso opportune interfaccie al Business Layer
Ogni Livello dell'applicazione conterrà una serie di componenti che implementano le funzionalità necessarie per tale livello. Ogni componente deve essere un entità attiva autonoma, indipendente dalle altre è in grado di cooperare. Sotto è mostrata la figura dove per ogni livello vengono indicati i sottolivelli con i relativi componenti, seguirà poi la descrizione di tali componenti .
Fig.3 Tipi di componenti comunemente trovati in ogni livello.
Componenti del Livello di Presentazione.
I Componenti del livello di presentazione implementano le funzionalità richieste per permettere agli utenti di interagire con l'applicazione. Ie seguenti tipologie di componenti possono far parte di tale livello:
• User Iterface Component(UIC). Questi componenti implementano i meccanismi per l'interazione Utente-Applicazione. Le funzionalità implementate riguardano ad esempio la formattazione e il Rendering dei dati, l'acquisizione e validazione dei dati.
• UIP Component (User Interface Process conponent). Componenti per gestire l'interazione con l'utente attraverso codice più portabile e modulare evitando di inserire il codice per la gestione dello stato negli elementi dell'Interfaccia utente.
Componenti del Livello Business.
Tali componenti implementano le funzionalità di base del sistema. I seguenti tipi di componenti possono appartenere al Business Layer:
• Application Façade. Sono dei componenti utili quando si lavora in una ambiente distribuito, ad esempio quando il livello di presentazione risiede in uno strato fisico separato dalla quello in cui risiedono i livelli di business e accesso ai dati. Permettono di incapsulare più operazioni del livello business in un singolo messaggio da inviare tra i vari livelli permettendo di ottimizzare le comunicazioni tra i vari livelli
• Business Component. Questi componenti implementano la logica business della applicazione
• Business WorkFlows. I dati che arrivano al livello business possono essere elaborati attraverso un processo business chiamato BW(Business WorkFlow) e composto da più fasi da eseguire secondo uno specifico ordine.
• Business Entity Components. Le Entità Business(Business Entity, BE) sono usate per passare i dati tra i vari componenti. Le entità che l'applicazione usa internamente sono solitamente strutture dati quali Dataset, DataReader, Stream XML, oppure classi costruite apposta che rappresentano le entità reali che l'applicazione può gestire.
Componenti del Livello di Accesso ai Dati.
Tali componenti forniscono accesso ai dati presenti nelle varie sorgenti. le seguenti tipologie di componenti possono appartenere al DAL(Data Access Layer, Livello di Accesso ai Dati):
• Data Access Component. Questi componenti astraggono la logica richiesta per accedere ai sottostanti dati immagazzinati nelle varie sorgenti.
• Data Helper. e Utility Component. La maggior parte delle funzionalità di accesso ai dati richiede una logica che può essere estratta e implementata in componenti autonomi e cooperanti tra di loro detti Helper Component. Questo aiuta a ridurre la complessità dei moduli per l'accesso ai dati e centralizza la logica semplificandone dunque il mantenimento. Altri Componenti che sono comuni a questo livello possono classificati come Utility Components.
• Service Agents. Quando un business component deve far uso di funzionalità messe a disposizione da un servizio esterno può essere necessario implementare del codice per la gestione dei protocolli di comunicazione con quel particolare servizio. I Service Agents forniscono servizi aggiuntivi di conversione tra il formato dei dati restituiti da servizio e il formato dei dati che accetta in input l'applicazione.
Componenti usati da tutti i livelli (Cross-Cutting Component).
Esistono dei componenti che racchiudono funzionalità usate e accessibili da entrambi i livelli.
Questi sono I Cross-Cutting Component e possono essere cosi suddivisi:
• Componenti che implementano la sicurezza. Ovvero componenti che si occupano dell'autenticazione,autorizzazione e validazione.
• Componenti che implementano funzionali di gestione del sistema. Ad esempio la gestione degli errori, e funzionalità quali Logging, Tracing e configurazione del sistema.
• Componenti per implementare la comunicazione. Questi possono includere componenti che comunicano con altri servizi e applicazioni.
Entità Business usate dai livelli di accesso dati e Business.
Ci sono molti casi in cui entità business devono essere accessibili ai componenti e servizi del Business Layer e del Data Access Layer. In ogni caso è buona pratica separare sempre la logica business dal DAL. Si può ottenere ciò inserendo entità business in assembly separati
che possono essere condivisi tra DAL e Business Layer.
Scegliere i Livelli appropriati per la realizzazione di un applicazione.
L' approccio a livelli permette di migliorare il mantenimento del software dell'applicazione, e semplifica il processo di miglioramento delle prestazioni. Applicare un approccio massiccio della progettazione a livelli aggiunge complessità all'applicazione, e ciò si ripercuote negativamente nella fase di sviluppo iniziale. Alcune regole base possono aiutare nella scelta di quanti e quali livelli aggiungere:
• Usare l'interfaccia utente(UI) solo quando richiesto.
• Se la tua applicazione non necessita di un business layer non inserirlo, è questo il caso in cui un applicazione implementa molta della logica nelle funzionalità del DAL e non sono richieste elaborazioni aggiuntive nel livello di business, ma bisogna soltanto visualizzare i dati cosi come appaiono.
• In Applicazioni Web, Valutare se lo sviluppo di componenti business nello stesso strato fisico in cui è presente il livello di presentazione può permettere un miglioramento delle prestazioni e un Cross-Cutting Layer più semplice da implementare.
• In applicazioni RIA dove le interfacce utente sono presenti sul desktop, è preferibile lo sviluppo di componenti che sono usati in modo sincrono dalle UI
• sviluppare componenti per i servizi nello stesso livello del codice che chiama i componenti a meno che per motivi di sicurezza sia richiesta una separazione delle due entità.
• sviluppare componenti business che comunicano in modo asincrono, e servizi business che risiedono su strati fisici separati dove è possibile.
Gli Strati(Tiers).
Gli strati rappresentano la separazione fisica delle funzionalità dei livelli di Presentazione, Business e Accesso ai Dati nei vari sistemi. I modelli architetturali per la strutturazione dei vari strati distinguono tra 2-Tier 3-Tier e N-Tier.
2-Tier.
Il modello a due strati rappresenta la struttura base con 2 componenti principali, un client ed un server. In questo scenario il client ed il server possono risiedere sulla stessa macchina o essere localizzati su due differenti macchine. La figura sotto illustra uno scenario comune per un Applicazione Web dove il client interagisce con il Web Server localizzato nello stesso strato del client. Questo strato contiene la logica del livello di Presentazione più la logica del livello Business. L'applicazione Web comunica con una macchina che ospita lo strato contenente il Database e il Livello di acceso ai dati.
Fig 4. Architettura a 2 strati .
3-Tier
In un Architettura a 3 Strati, Il client interagisce con il software sviluppato su server separati, e l'Application Server interagisce con il database anch'esso localizzato su un server separato.
Questo è un modello architetturale comune per la maggior parte delle Applicazioni Web e per i Servizi Web .
Fig 5. Architettura e 3 strati.
N-Tier
in questo scenario, il Web Server (che contiene il livello di presentazione) è fisicamente separato dall'Application Server che implementa la logica di business. Questo solitamente accade per ragioni di sicurezza, quando il Web Server e l'Application Server sono fisicamente su due Sub net separate e si può accedere all'Application Server soltanto attraverso firewall.
E' pratica comune implementare un firewall tra Client e Strato Web.
Fig 6. Architettura a N-strati
Scegliere gli Strati Per lo sviluppo di una applicazione.
La strutturazione dei livelli su Strati Fisici può aiutare la performance distribuendo il carico di lavoro su più server. Come contro indicazione l'aggiunta di strati aumenta la complessità dello sviluppo della applicazione, dunque è controindicato aggiungere tanti strati più di quanti sono necessari. Anche se spesso è sufficiente un singolo strato per tutti i livelli, esistono tantissime altre situazioni in cui conviene separare in più strati i livelli, ad esempio quando :
• In un contesto Client/Server o a 2-Trier si presentano le seguenti situazioni
• bisogna sviluppare i Client che devono accedere ad un Application Server
• bisogna sviluppare un Client stand-alone che accede a database remoti
• In un contesto 3-Tier si presentano le seguenti situazioni
• bisogna sviluppare una applicazione che opera in una intranet dove tutti i server sono localizzati in una rete privata.
• bisogna sviluppare una applicazione Web, con vincoli di sicurezza non troppo stringenti
• In un contesto N-Tier si presentano le seguenti condizioni
• Requisiti di sicurezza sono tali da dover separare logica del livello Business in uno strato separato
• L'applicazione fa un pesante uso di risorse sul server ragione per cui occorre distribuire i livelli su più strati.
Approcci ai 3 Livelli e Tecnologie Usate.
Approccio al Livello di Presentazione.
Il seguente paragrafo descrive il processo da adottare quando si progetta il Presentation layer Questo approccio assicura che vengano presi in considerazione tutti i fattori rilevanti lo sviluppo della architettura:
1. Identificare il tipo di client con cui si interagisce. Scegliere il tipo di client che soddisfa requisiti e aderisce all'infrastruttura e ai vincoli di sviluppo;
2. Determinare come presentare i dati. Scegliere il formato per i dati più opportuno e per la loro presentazione.
3. Decidere la strategia di validazione dei dati.
4. Decidere quale strategia per il business layer adottare
5. Determinare la strategia per le comunicazioni con gli altri livelli
Approccio al livello Business.
Quando si progetta il Business Layer, bisogna tenere a mente i requisiti di progettazione per gli elementi principali del livello ovvero i business component, business entities, e il business Workflow Component. Questa sezione brevemente spiega le attività principali coinvolte nella progettazione di tutti i componenti sopracitati. Eseguire i seguenti punti in ognuna delle seguenti aree quando si progetta tale livello
1. Realizzare una progettazione globale del business layer ovvero 1. Identificare l'utilizzatore del business layer;
2. Determinare come poter esporre il business layer;
3. Determinare i requisiti di sicurezza per il business layer;
4. Determinare i requisiti di autenticazione e le strategie di validazione per il Business layer.
5. Determinare la politica di Caching da adottare per il Business layer 6. Determinare la strategia più appropriata per gestire le eccezioni.
2. Progettare i Business Component
1. Identificare i componenti business che l'applicazione userà
2. Prendere decisioni circa la localizzazione, raggruppamento e interazione per i Business Component
3. Scegliere un Appropriato supporto alle transazioni
4. identificare come le regole del Business Layer possono essere gestite 5. Identificare i pattern che risolvono i requisiti
3. Progettare i business entity component
1. individuare i formati possibili per i dati per le business entity 2. Scegliere il formato dei dati
3. Opzionale, Scegliere uno schema per gli oggetti “custom”
4. Opzionale, determinare come tu puoi puoi serializzare i componenti 4. Progettare il workflow component
1. Identificare la struttura del workflow sulla base degli scenari possibili 2. Determinare come sono gestite le regole del workflow
3. Progettare i business component per il workflow
Le tecnologie che possono essere usate per implementare il business layer o in supporto al business layer sono
• Se è richiesto un Workflow che automaticamente supporti scambio di dati sicuro affidabile, dotato di supporto alle transazioni, allora si può usare la tecnologia Windows WorkFlow Foundation (WWF).
• Se si richiede un workflow che implementi una gestione complessa del Workflow e un supporto affidabile per immagazzinare e inviare messaggi, considera Microsoft BizTalk Server.
• Se il business layer è confinato su un unico sito Microsoft Office Share Point e non richiede accesso alle informazioni di altri siti, allora si può usare MOSS.
• Se tu stai progettando transazioni che coinvolgono più sorgenti dati allora considera l'uso della libreria System.Transaction per gestire l'intera transazione
Approccio al Livello di Accesso ai dati
Un corretto approccio alla progettazione del data layer ridurrà il tempo di sviluppo e permetterà il mantenimento del livello stesso dopo che l'applicazione è sviluppata. Questa sezione brevemente mostra la progettazione del data layer. I Seguenti passaggi mostrano cosa si deve fare
1. Elaborare la progettazione globale per il DAL 1. Identificare i requisiti del DAL
2. Determinare una strategia per l'accesso ai Dati
3. Scegliere come mettere in correlazione strutture dati con sorgenti dati 4. Determinare come connettersi alla sorgente dati
5. Determinare le strategie per la gestione degli errori 2. Progettare i componenti per l'accesso ai dati
1. Individuare quante e quali sorgenti dati a cui si vuole accedere 2. Decidere circa il metodo di accesso per ogni DataSource
3. Determinare i componenti di aiuto(Data Helper Component)che sono richiesti o conviene siano presenti per semplificare lo sviluppo e il mantenimento dei componenti per l'accesso ai dati
4. Determinare quali pattern progettare.
3. Progettare i Data Helper Component
1. Identificare le funzionalità comuni a tutti i componenti Data Access Component 2. Selezionare le librerie disponibili per Data Helper Component
3. Valutare la realizzazione di funzioni per il test dei Data Helper component
4. Valutare la possibilità di implementare e gestire le funzionalità di Logging per i DAC(Data Access Component )
4. Progettare i Service Agents.
1. usare Tool appropriati per aggiungere un Service Agent.
2. Determinare come il servizio sarà usato nella applicazione.
Quali Tecnologie usare :
• Nel caso di supporto base per query parametriche si può usare la tecnologia ADO.NET
• Nel caso di accessi ai dati complessi, o se si vuole semplificare il codice per l'accesso ai dati si può usare la Enterprise Library Data Access Application Block.
• Per la costruzione di Data Driven Web Application basate sulla struttura della sorgente dati allora si può usare il ASP.NET Dynamic Data .
• Se si usa ASP.NET per creare interfacce utente si può usare L'oggetto DataReader per accedere ai dati e ottimizzare le performance.
• Se si lavora con SQL SERVER si possono usare le librerie di ADO.NET
Architettura di una Applicazione Web.
Il core di una Applicazione Web è la sua Logica Lato Server. Un tipico esempio è una Architettura a 3 livelli, comprendente i livelli di presentazione business e di accesso ai dati, mentre i componenti comuni ai tre livelli vengono raggruppati in un livello a parte.
Fig.7. Architettura tipica di una Web Application
Considerazioni sulla Progettazione di un Applicazione Web.
Quando si progetta una applicazione Web, I punti chiave da seguire sono la minimizzazione della complessità del progetto scomponendo l'applicazione in aree distinte con lo scopo di garantire i requisiti di sicurezza e performance.
Sotto sono indicate alcune delle linee guida necessarie nella progettazione:
• Partizionare logicamente l'applicazione. Usare il partizionamento logico della applicazione nei tre livelli. Questo aiuta a creare un codice mantenibile che permette di ottimizzare la performance di ogni livello separatamente.
• Usare l'Astrazione per raggruppare funzionalità comuni a più livelli. Ciò può essere attuato attraverso la definizione di interfaccie, e avendo stabilito i formati di input e output è possibile tradurre richieste da un formato ad un altro.
• Capire come i livelli comunicano tra loro. Questo richiede la comprensione dello scenario in cui l'applicazione verrà sviluppata. Bisogna determinare se le comunicazioni avvengono su più strati separati oppure risiedono su uno stesso strato.
• Ridurre le richieste sincrone. Questo è un requisito fondamentale che permette di migliorare le performance e realizzare un applicazione più semplice da gestire. Ciò è possibile attraverso il Caching e l'Output Buffering per ridurre le comunicazioni Client-Web Server, e tra il Web Server e gli altri Server.
• Usare i principi del Caching. Una strategia di Caching è un altro requisito necessario per una progettazione orientata alle performance. Per esempio la tecnologia ASP.NET implementa il Caching attraverso le funzionalità di output-caching, partial-page -caching e Cache-API.
• Implementare le Caratteristiche di Logging. Occorre implementare una strategia per tracciare le operazioni svolte nell'applicazione. Questo permette di rilevare possibili problemi a Run-Time più le attività sospette.
• Cercare di ridurre le operazioni bloccanti per l'applicazione. Se si necessita di implementare operazioni bloccanti per l'applicazione, magari con un tempi di esecuzione lunghi occorre usare un approccio asincrono in modo tale da permettere al Web Server di processare altre richieste in ingresso
• Implementare il processo di autenticazione. La gestione degli utenti all'inteno dell'Applicazione costituisce di fatto un processo complesso. Bisogna considerare le problematiche di personalizzazione di un applicazione sulla base delle varie tipologie di utenti con i rispettivi ruoli. L'accesso all'applicazione da parte di utenti disabili o
non più autorizzati ad eseguire operazioni, non che l'accessibilità alle varie aree del sito e la personalizzazione dello stesso.
• Criptare dati sensibili. Una altra questione che bisogna tenere in mente è il passaggio di dati e codice tra i vari livelli, non dimenticando che sia i dati che riguardano gli utenti che il codice che risiede sul client devono essere criptati.
Problemi tipici nello sviluppo di Web Application.
Requisito/ Caratteristica Problema Tipico nello sviluppo
Autenticazione • Password in chiaro nel Database
• Gestione personalizzata dei meccanismi di autenticazione senza alcun utilizzo dei meccanismi offerti dalla tecnologia
Autorizzazione • Progettazione non corretta delle
tipologie di utenti con relativi ruoli
Caching • Effettuare il Caching di dati volatili
• Effettuare il Caching di dati sensibili
• Non implementare/usare il cache page output
Gestione Eccezioni • Dare la possibilità all'utente di vedere informazioni riguardo i dettagli dell' errore
Logging • Fornire un sistema di Logging non
sufficientemente dettagliato o non completo
• non fornire un supporto a run time per gestire l'attività di logging
Navigabilità • Unire le caratteristiche di navigabilità
del sito con le componenti dell'interfaccia utente
• Non attuare politiche che permettano di decidere la navigabilità delle pagine dell'applicazione a seconda della tipologia dell'utente o implementarle in modo incompleto e scorretto
Interfaccia utente • Usare Layout basati su tabelle
• Progettare pagine troppo complesse
• Progettare Pagine “OverLoaded”
Requisito/ Caratteristica Problema Tipico nello sviluppo
Rendering della Pagina • Utilizzo massiccio di Post-Back per il Refresh della pagina a seguito di interazioni con l'utente
• Implementare pagine di grandezza eccessiva
Presentation Entities • Creare oggetti customizzati quando non è richiesto
• unire la logica business alla logica di presentazione
Elaborazione delle Richieste • Fondere la logica di elaborazione con la logica di Rendering
• Scegliere i Pattern non Appropriati
Gestione delle Sessioni • Utilizzare meccanismi per
memorizzare le informazioni, inappropriati e pesanti
• non considerare i requisiti di serializzazione
• Rendere i dati di sessione non persistenti
Validazione • Errori nell'implementazione della
validazione Server-Side.
• Implementare una logica di validazione non riutilizzabile in altre applicazioni
Di seguito sono elencate e descritte tutte le caratteristiche di una applicazione Web con relative linee guida per una corretta progettazione.
Autenticazione
Progettare una strategia di autenticazione effettiva è importante per la sicurezza e l'affidabilità della applicazione. Una gestione inefficiente può rendere l'applicazione vulnerabile dagli attacchi condotti da hacker.
Considera le seguenti linee guida nella progettazione di una strategia di autenticazione:
• Identificare i confini tra i livelli della applicazione Web. Questo aiuterà a determinare dove applicare le regole di autenticazione.
• Usare meccanismi di autenticazione supportati dalla Piattaforma, come Window Authetication, quando possibile.
• Se si utilizzano i Form Authentication, in tale situazione occorre affidarsi a meccanismi come i Role-Membership Provider
• Fare un utilizzo massiccio di politiche di gestione come Account Lockout e account Expiration.
• Fare uso massiccio di politiche per la gestione delle password;
Autorizzazione
Il processo di autorizzazione determina le operazioni che un utente autenticato può eseguire e identifica le risorse a cui si può accedere. Progettare strategie di autorizzazione è importante per la sicurezza e l'affidabilità dell'applicazione.
Alcune regole da seguire:
• Identificare i confini dei livelli della applicazione Web e gestire le autorizzazione su tali livelli.
• Utilizzare Controlli di accesso per Pagine e directory Caching
Il Caching migliora le prestazioni del sistema e la velocità di risposta delle Pagine Web. In Ogni caso scelte non corrette nell'implementazione del Caching possono portare ad una degradazione della performance. Bisogna implementare il Caching per ottimizzare gli accessi alle tabelle di lookups, ridurre il più possibile i Round Trip, eliminare elaborazioni non necessarie. Per implementare il caching è necessario innanzitutto decidere quando caricare i dati nella cache. Bisogna poi caricare i dati in modo asincrono o attraverso processi batch per ridurre i ritardi nei tempi di risposta dei client.
I passi da seguire sono:
• Non implementare il Caching di dati volatili cioè dati non permanenti
• Usare Output Caching per effettuare il Caching di pagine che sono statiche.
• Utilizzare il Partial Page Caching per dati statici da utilizzare all'interno delle pagine
• Non effettuare il caching di risorse quali network connection
• Effettuare il caching dei dati in formato pronto per l'uso
Gestione delle Eccezioni.
La progettazione di una strategia di gestione delle eccezioni è importante per la sicurezza e l'affidabilità della tua applicazione. Una Corretta gestione degli errori rende l'applicazione più robusta e permette di evitare di portare il sistema in stati inconsistenti quando avviene un errore.
Considera i seguenti punti:
• Non fare utilizzo di eccezioni per controllare il flusso delle operazioni
• Progettare un gestore globale come singolo punto di centralizzazione in cui convogliare la gestione di tutte le eccezioni catturate
• Visualizzare Messaggi User-Friendly all'utente finale quando un errore o un eccezione avvengono
• Non rivelare informazioni sensibili quando si restituisce la descrizione e i dettagli degli errori
Logging.
Progettare un Logging efficace è importante per ragioni di sicurezza e affidabilità del sistema. Occorre creare e gestire Log di sistema attraverso i vari strati del sistema.
Tali logs servono per monitorare le attività critiche che vengono elaborate nel sistema e tracciare tutte le operazioni in modo tale da rilevare attività sospette.
I passi chiave sono:
• Considerare il monitoraggio degli eventi riguardanti la gestione degli utenti
• Considerare il monitoraggio di attività inusuali
• Considerare il monitoraggio di operazioni business-critical
• Creare politiche di gestione sicure per i file di log.
• Non immagazzinare informazioni sensibili nei file di log come password.
Gestione Navigabilità Del sito
La progettazione di una strategia di Navigabilità del sito, ovvero come strutturare i collegamenti tra le varie pagine in modo tale da semplificarne la navigazione, deve essere tale da separare tale logica, dalla logica di elaborazione dei contenuti. La scelta della struttura generale del sito ha come scopo la possibilità di rendere più utilizzabile l'applicazione.
I Passaggi chiave sono:
• Usare Patterns noti come l'MVP, per separare l'interfaccia utente dal processo di Rendering
• Cercare di incapsulare i meccanismi principali per la navigazione di un sito nella Master Page.
• Progettare una Site Map per aiutare gli utenti a trovare pagine nel sito e per permettere ai motori di ricerca di indicizzare l'applicazione.
Page Rendering
Quando si progetta il Rendering delle pagine, bisogna assicurare un caricamento della pagina veloce e massimizzare l'usabilità dell'interfaccia utente.
Alcuni consigli:
• Usare Controlli DataBinding forniti dal Framework ASP.NET
• Usare AJAX per migliorare l'usabilità del sito e diminuire i tempi di risposta del sistema
• Utilizzare Tecniche di Data-Paging per Pagine di grandezza notevole
• Considera la progettazione di un supporto per la gestione della lingua e delle impostazioni sulla cultura e nazione di appartenenza degli utenti che visitano l'applicazione
Presentation Entity.
I Presentation Entities immagazzinano i dati usati per la gestione delle viste nel livello di presentazione. Tali elementi non sono sempre necessari. Considera tali entità soltanto se i DataSet sono sufficientemente grandi o complicati tali da essere separati dai componenti UI.
Progetta o scegli presentation entity soltanto se puoi collegarli con semplicità ai i componenti UI.
Considera le seguenti guide linee quando progetti PE:
• Determinare se si ha la necessità di Presentation entities.
• Considerare i requisiti di serializzazione per le tue PE, se loro devono essere passati attraverso la rete o memorizzati sul disco
• Implementare i controlli di validazione sui tipi di dati
• Utilizzare presentation entities per memorizzare lo stato relativo alle UI
Elaborazione delle Richieste
Quando si elaborano strategie di elaborazione delle richieste, bisogna assicurare la separazione dei vari concetti ovvero implementare la logica dell'elaborazione delle richieste dalla UI. Considera le seguenti linee guida quando si progetta una strategia di gestione ed elaborazione delle richieste:
• Centralizzare i passaggi comuni di Pre-Processing e Post-Processing di una richiesta ad una pagina Web
• Dividere il processo di UI in tre ruoli distinti – Model, View, e Controller/Presenter, ovvero i pattern MVC e MVP.
Gestione delle Sessioni
Un accurata Gestione delle Sessioni permette un miglioramento delle performance e dell'affidabilità. Alcuni fattori tipici della gestione delle sessioni sono: cosa devono memorizzare, dove memorizzare le informazioni di sessione, per quanto tempo mantenere le informazioni sulla sessione.
I passi guida sono:
• Se Si ha un singolo Web Server, con l'esigenza di avere una gestione performante dello stato della sessione e con un numero limitato di sessioni concorrenti usare il pattern in-process state store
• Se Si ha singolo Web Server, se le sessioni sono costose da ricostruire, e se è richiesta la persistenza della sessione anche quando ASP.NET viene fatto ripartire, allora bisogna usare il servizio per la gestione dello stato che gira sul Web Server Locale.
• Usare il servizio di gestione remota delle sessioni o MSQLSERVER state store nel contesto delle Web-Farm
• Se si memorizzano informazioni sullo stato su server separati, allora è necessario pensare a canali di comunicazione protetti per lo scambio di informazioni circa le sessioni
Validazione.
Il processo e i meccanismi di validazione sono necessari per i requisiti di affidabilità e sicurezza.
Passi chiave:
• Identificare confini sicuri tra i livelli dell'applicazione e validare tutti i dati che passano per questi confini
• Assumere che tutti i dati controllati dal client sono malevoli e devono essere validati
• Progetta la strategia di validazione per limitare, rifiutare e rendere innocuo input malevolo
• Progettare la validazione dell'input sulla base di lunghezza, intervallo di valori possibili, formato e tipo di dati.
• Usare validazione lato client attraverso l'utilizzo di AJAX.
Considerazioni sul livello di presentazione di una Web Application
Il livello di presentazione di una Web Application visualizza la UI e agevola l'interazione con l'utente. La progettazione dovrebbe focalizzarsi sulla separazione dei concetti, Ovvero La logica di interazione con l'utente deve staccarsi dalle componenti UI. Linee guida nella progettazione:
• Separare gli UI Component dai UI Process component
• usare controlli client-side validation per migliorare la rapidità nelle risposte e l'usabilità, e utilizzare server-side validation per ragioni di sicurezza
• usare page output caching e fragment caching per effettuare il cache di pagine statiche o di parti di pagine
• utilizzare Web Server Controls se si necessita di compilare questi controlli in assembly per poi riusarli
Considerazioni sul livello business di una Web Application
Il problema principale nella progettazione di un business layer è come implementare la logica business e la logica long-running workflow. Linee guida da realizzare
• Progettare un livello business separato che implementi e divida la logica business dal workflow. Questo migliora la mantenibilità e la testabilità della applicazione
• Centralizzare e riusare le Funzioni comuni a tutti le fasi del livello business
• Progettare il Business Layer come privo di stato.
• Usare interfacce basate sullo scambio di messaggi per il Business Layer.
• Progettare transazioni per il le operazioni business critiche Considerazioni sul Data access Layer(DAL).
Utilizzato per accedere al database, l'uso di un Data Access Layer può rendere l'applicazione semplice da configurare e mantenere. Linee Guida:
• Progettare un DAL per nascondere i dettagli del DB dagli altri Livelli
• Progettare oggetti che interagiscono con gli altri livelli e si scambiano i dati tra i vari livelli
• configurare e abilitare il Connection Pooling per la gestione di più connessioni aperte
• Progettare una gestione delle eccezioni per gestire gli errori sugli accessi ai dati e propagare tali errori al business layer.
• utilizzare batch operation Considerazione sui Test
La testabilità della applicazione va pianificata quando si costruisce l'architettura perchè permette di rilevare problemi subito e riduce i costi di mantenimento. Per migliorare la testabilità della tua applicazione bisogna affidarsi alla gestione dei Log di sistema effettuare il monitoraggio delle risorse, e implementare interfacce di Test. Passi giuda:
• Definire input e output della applicazione e dei componenti durante la fase di progettazione
• Usare il pattern Passive-View, nel livello di presentazione perché rimuove le dipendenze tra la vista e il modello
• Progettare un accurata efficace strategia dei log che permetta di rilevare errori altrimenti difficili da trovare. I file di log devono fornire tutte le informazioni per poter riprodurre l'errore, e devono aiutare a capire quale porzione di codice lo genera.
• Selezionare i componenti che possono essere testati individualmente, e quelli che devono essere testati in gruppo
Considerazioni sulla Performance
I requisiti di performance richiesti dall'applicazione che si progetta possono essere recuperati dalla fase di analisi dei requisiti non funzionali. Le linee guida sono:
• Assicurarsi che i requisiti di performance siano specifici, realistici e flessibili
• Implementare politiche di cache può migliorare performance scalabilità
• Operazioni Batch possono minimizzare il Round-Trip.
• Ridurre il volume dell'HTML trasferito tra server e client. Per esempio si potrebbe disabilitare il View State quando non è utilizzato; limitare l'uso massiccio di grafica e considerare l'utilizzo di grafica compressa
• Eliminare i Round-Trip quando possibile Considerazioni sulla Sicurezza
La sicurezza nelle Web Application serve per garantire requisiti di integrità e privacy dei dati e delle risorse. Per implementare il requisito di sicurezza si può/deve ricorrere a soluzioni standard provate e testate, deve implementare i concetti di autenticazione, autorizzazione, e validità dei dati per proteggere l'applicazione.
Passi Chiave da seguire:
• Utilizzare l'autenticazione.
• Implementare meccanismi restrittivi per l'autorizzazione al fine di proteggere risorse e la logica business;
• Considerare la validazione dell'input
• Utilizzare la validazione Server-Side.
• Criptare dati sensibili e codice che viaggia sulla rete
Considerazioni sulle Tecnologie da usare
Riguardo alla piattaforma Microsoft , tecnologia di riferimento è ASP.NET. Le altre tecnologie utilizzabili sono ASP.NET AJAX, ASP.NET MVC, SilverLight, ASP.NET Dynamic Data. Le guide linea nella scelta delle varie tecnologie sono
• Se si vogliono costruire applicazioni che sono accessibili attraverso il browser allora si può usare ASP.NET
• Se si vogliono costruire applicazioni che forniscono alta interattività, con basso reload delle pagine allora si può usare ASP.NET AJAX.
• Se si vuole costruire applicazioni che includono contenuti multimediali di un certo spessore più interattività allora si può pensare ad ASP.NET più i controlli SilverLight .
• Se si utilizza ASP.NET considera l'utilizzo delle master page per implementare UI consistenti.
• Se si deve costruire una Applicazione Web orientata ai Dati con le pagine basate sul modello dei dati del DB sottostante considera l'utilizzo di ASP.NET Dynamic Data
.NET - LINQ e Studio Delle Performance
Entity Framework è un insieme di tecnologie ADO.NET che supportano lo sviluppo di applicazioni software orientate ai dati. Gli architetti e gli sviluppatori di questo tipo di applicazioni si trovano nella difficile condizione di dover realizzare due obiettivi molto diversi tra loro, ovvero la modellazione delle entità, delle relazioni e della logica dei problemi aziendali che sono preposti a risolvere e al tempo stesso gestire i motori dei dati utilizzati per archiviare e recuperare i dati stessi. Dal momento che i dati potrebbero essere distribuiti in più sistemi di archiviazione, ciascuno con i suoi protocolli, è necessario che nelle applicazioni che gestiscono un solo sistema di archiviazione, venga rispettato l'equilibrio tra i requisiti del sistema di archiviazione e i requisiti di scrittura di codice dell'applicazione efficiente e gestibile. Entity Framework consente agli sviluppatori di utilizzare i dati sotto forma di proprietà e oggetti specifici di un dominio, ad esempio clienti e indirizzi dei clienti,
indipendentemente dalle colonne e dalle tabelle di database sottostanti in cui sono archiviati.
Per ottenere questo risultato, è necessario elevare il livello di astrazione al quale gli
sviluppatori possono lavorare quando gestiscono i dati e ridurre il codice richiesto per creare e gestire le applicazioni orientate ai dati. Poiché Entity Framework è un componente del .NET Framework, le applicazioni Entity Framework possono essere eseguite su qualsiasi computer in cui è installato .NET Framework 3.5 Service Pack 1 (SP1).
Le applicazioni Entity Framework offrono i vantaggi seguenti:
• Le applicazioni possono funzionare in termini di modello concettuale più incentrato sull'applicazione, includendo tipi con ereditarietà, membri complessi e relazioni.
• Le applicazioni non dipendono a livello di codice da un motore dei dati o da uno schema di archiviazione specifico.
• È possibile cambiare il mapping tra il modello concettuale e lo schema specifico dell'archiviazione senza modificare il codice dell'applicazione.
• Gli sviluppatori possono utilizzare un modello a oggetti dell'applicazione coerente che può essere mappato ai diversi schemi di archiviazione, che possono essere
implementati in sistemi di gestione di database diversi.
• È possibile mappare più modelli concettuali a un unico schema di archiviazione.
• Il supporto LINQ (Language Integrated Query) consente di convalidare in fase di compilazione la sintassi delle query su un modello concettuale allargato, il .NET Framework 3.5 Service Pack 1 (SP1).
Realizzazione dei modelli concettuali
Uno schema di progettazione comune e ormai consolidato per la modellazione dei dati prevede la suddivisione del modello di dati in tre parti: un modello concettuale, un modello logico e un modello fisico. Il modello concettuale definisce le entità e le relazioni nel sistema da modellare. Il modello logico per un database relazionale normalizza le entità e le relazioni in tabelle con vincoli di chiave esterna. Il modello fisico infine gestisce le funzionalità di un determinato motore dei dati specificando dettagli sull'archiviazione come il partizionamento e l'indicizzazione.
Entity Framework favorisce la realizzazione dei modelli concettuali in quanto consente agli sviluppatori di eseguire query su entità e relazioni del modello concettuale basandosi al tempo stesso su Entity Framework per convertire le operazioni in comandi specifici dell'origine dati.
Le applicazioni non sono quindi più vincolate a dipendenze hard-coded su una determinata origine dati. Il modello concettuale, il modello di archiviazione e il mapping tra i due modelli sono espressi in una specifica esterna, nota come Entity Data Model (EDM). Il modello di archiviazione e i mapping possono cambiare in base alle esigenze senza richiedere modifiche al modello concettuale, alle classi di dati o al codice dell'applicazione. Poiché i modelli di archiviazione sono specifici del provider, è possibile utilizzare un modello concettuale coerente in varie origini dati.
In Entity Data Model (EDM) le relazioni modellano connessioni logiche tra entità. Il modello EDM supporta il tipo AssociationType di relazione che modella la relazione peer-to-peer tra le entità. In un'associazione ogni entità partecipante è definita End. Ogni elemento End presenta un attributo Role utilizzato per denominare e descrivere la logica di ciascun elemento End dell'associazione. Gli attributi Type nelle entità finali di un'associazione definiscono i tipi di entità che partecipano alla relazione.
Le associazioni dispongono di un attributo Multiplicity. Tale attributo specifica il numero di istanze di ciascun elemento End che può partecipare alla relazione.
Nella logica di numerose applicazioni line-of-business, i clienti effettuano gli ordini e gli ordini devono essere recapitati ai clienti. La relazione tra un cliente e un ordine può essere modellata da un'associazione EDM. Le entità finali dell'associazione sono le entità cliente e ordine. Ogni elemento End presenta un'entità Type. L'attributo Role descrive la funzione dell'entità specificata dall'attributo Type. Nella maggior parte dei casi, ogni cliente può
disporre di zero o più ordini, ma un ordine è associato a esattamente un cliente. In altre parole, l'attributo Multiplicity è pari a 1 per il tipo di cliente e a * per l'ordine.
