3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Principalmente possiamo individuare due modalità per rappresentare i dati nell'ambito del dominio applicativo:
- domain model: si tratta di un insieme di classi personalizzate (custom entities) che concorrono ad identificare un modello ad oggetti; ciascuna classe identifica un'entità del dominio reale e la rappresenta tramite una serie di proprietà. Le relazioni tra entità sono espresse tramite riferimenti ad altre entities: in questo modo il modello ad oggetti che ne consegue è un grafo più o meno complesso di associazioni tra classi diverse (vedi figura 2);
- container di dati: si tratta di un'unica classe che al suo interno contiene una rappresentazione delle informazioni che deriva direttamente dalla struttura della sorgente dati. Gli esempi più significativi sono rappresentati dai DataSet e dalle DataTable, che organizzano le informazioni al loro interno in matrici di dati (Table), eventualmente relazionate tra loro in base ai metadati ricavati dallo schema originario.
Figura 2: esempio di modello ad oggetti (domain model).
La scelta tra le due soluzioni evidenziate si basa principalmente sulla valutazione dei benefici e degli svantaggi di ciascun approccio in relazione alle specifiche esigenze di disegno e alla tipologia dell'applicazione.
Se da un lato un approccio basato su container di dati si può rivelare vantaggioso in termini di velocità di sviluppo e duttilità, dall'altro l'approccio basato sulla definizione di un modello ad oggetti personalizzato comporta una serie di vantaggi non trascurabili:
- tipizzazione: le proprietà delle entities sono tipizzate in base ai valori che contengono diversamente da quanto avviene nei DataSet e nelle DataTable, dove ogni dato viene rappresentato come oggetto generico (tipo System.Object);
- serializzazione: i costi di serializzazione delle entities sono inferiori rispetto a quelli dei DataSet o delle DataTable; questo aspetto ricopre un certa importanza in scenari che prevedono l'utilizzo di web service piuttosto che l'uso della Session di ASP.NET;
- focalizzazione: ciascuna entities è specializzata a contenere un insieme di dati ben preciso, presentando un'interfaccia snella e focalizzata;
- performance: la tipizzazione stretta e la focalizzazione delle entities produce un vantaggio in termini di performance, dal momento che le operazioni di boxing/unboxing dei valori vengono del tutto eliminate;
- disaccoppiamento: l'uso di entities personalizzate permette di modellare i dati in ambito applicativo in una forma non dipendente dalla loro rappresentazione e organizzazione all'interno della sorgente dati.
Anche se la soluzione basata su domain model richiede uno sforzo maggiore in termini di sviluppo, essa si rivela in molti casi l'approccio più indicato. La soluzione basata su DataSet o DataTable è preferibile in scenari particolarmente semplici, dove la performance e la scalabilità dell'applicazione non rappresentano vincoli importanti in termini progettuali.
Applicazioni web stratificate con ASP.NET
Nelle applicazioni web lo strato di presentazione è composto da una serie più o meno organizzata di pagine web, contenenti controlli, script e markup. I contenuti delle pagine derivano dall'interazione della UI con la logica applicativa che genera dinamicamente le informazioni da mostrare in risposta alle richieste provenienti dal client.
Il .NET Framework e, in particolare, ASP.NET forniscono una rappresentazione object-oriented delle pagine e dei controlli web, dotandoli tra l'altro di un meccanismo intrinseco basato su eventi per gestire in modo appropriato le interazioni degli utenti. Accanto al markup, il programmatore è chiamato a fornire l'implementazione del codice da eseguire in funzione degli eventi scatenati dai controlli, dalle pagine e, più in generale, da tutti gli oggetti che entrano in gioco nella gestione di una richiesta HTTP.
Sebbene sia possibile includere tutta la logica applicativa direttamente negli event handler di pagine e controlli, la scelta di una architettura a livelli obbliga il programmatore della UI ad utilizzare unicamente le funzionalità fornite dallo strato di business, senza peraltro obbligarlo a conoscerne i dettagli implementativi interni. Il vantaggio è quello di poter riutilizzare le stesse funzionalità in modo uniforme in più parti dello strato di presentazione, eliminando le duplicazioni di codice ed inserendo un meccanismo di protezione e isolamento tra i due stati, indispensabile per favorire la manutenibilità del codice a fronte di cambiamenti della logica applicativa.
In base a quanto detto, ne deriva che il codice associato a ciascuna pagina contiene riferimenti unicamente ad oggetti del BLL e chiamate a metodi delle classi di business. La comunicazione tra i due strati avviene attraverso lo scambio delle informazioni necessarie per eseguire le operazioni richieste, usando custom entities piuttosto che container di dati a seconda dei casi.
<asp:GridView ID="BookGrid" runat="server" AutoGenerateColumns="False">
<Columns>
<asp:BoundField DataField="ID" HeaderText="ID" />
<asp:BoundField DataField="Title" HeaderText="Titolo" />
<asp:BoundField DataField="Category" HeaderText="Categoria" />
</Columns>
</asp:GridView>
// Chiamata di un metodo del Business Logic Layer
// che ritorna un insieme di oggetti di tipo Book
BookGrid.DataSource = Books.GetList();
BookGrid.DataBind();
3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Contenuti
Stampa 
Download
