3 pagine in totale: <<Indietro 1 2 [3]
Esempio pratico: pubs
Affrontiamo ora il problema con un'approccio più pragmatico, considerando un'applicazione ASP.NET a tre livelli basata su domain model. L'esempio trattato nel proseguo dell'articolo si riferisce ad un catalogo online di libri, dove è possibile consultare i prodotti in vendita in funzione dei titoli, degli autori e delle case editrici. L'applicazione presa in esame utilizza come sorgente dati il database pubs (database di esempio presente in SQL Server 2000, installabile anche in SQL Server 2005). Il codice sorgente è disponibile in allegato all'articolo.
Figura 3: struttura della soluzione, dipendenze dei progetti e namespace.
La figura 3 mostra la struttura della soluzione in Visual Studio 2005. Come è possibile vedere nell'immagine, la soluzione si compone di quattro progetti:
- DotNetCircle.Rcd2.UI: rappresenta lo strato di presentazione, contiene principalmente le pagine ASPX dell'applicazione e le classi accessorie utilizzate nell'ambito della UI;
- DotNetCircle.Rcd2.Business: è il Business Logic Layer, contiene i servizi applicativi che vengono invocati all'interno delle pagine ASPX. Questi servizi si riferiscono unicamente alle regole di business che "lavorano" sulle entities e sulle collezioni tipizzate relative;
- DotNetCircle.Rcd2.Data: è il Data Access Layer, contiene le classi che permettono di comunicare con la sorgente dati, nel caso specifico un database di SQL Server. Questo strato rimappa le informazioni presenti nel dominio dei dati sulle entities che vengono utilizzate come oggetti di scambio verso il BLL;
- DotNetCircle.Rcd2.Common: rappresenta uno strato trasversale ai tre già citati, contiene le entities, le collezioni tipizzate e i servizi infrastrutturali di valenza generale come, per esempio, l'accesso alla configurazione o la validazione della querystring. Tutti i layer applicativi utilizzano le classi contenute in questo progetto.
Ciò che è interessante notare è che ogni progetto (e di conseguenza l'assembly relativo) presenta un insieme di dipendenze dagli altri progetti della soluzione che varia a seconda dei casi. Se DotNetCircle.Rcd2.Common è referenziato da tutti i progetti, così non è per gli altri. Lo strato di presentazione conosce i servizi dello strato di business, ma non dipende dal Data Access Layer. La logica di business referenzia il progetto relativo all'accesso ai dati, ma non dipende dallo strato di presentazione.
La scelta delle dipendenze per i progetti non è casuale, ma dipende da ciò che il progetto rappresenta all'interno della soluzione. Questo avviene perchè, come già detto in precedenza, esiste un ordine di relazione tra i vari strati. Questo approccio obbliga lo sviluppatore ad utilizzare in ogni progetto della soluzione unicamente le classi che sono effettivamente accessibili in base alle dipendenze. Eventuali eccezioni non sono ammesse, in quanto in caso contrario si verrebbe a violare la suddivisione logica dell'applicazione in strati.
Anche la scelta del nome dei vari namespace e la loro collocazione all'interno dei progetti non è casuale. Se da un lato l'associazione di una classe ad un namespace deve essere dettata dalla finalità della classe stessa, dall'altro la sua collocazione all'interno di un progetto (e quindi di un assembly) deve avvenire in funzione delle sue dipendenze.
Nella soluzione in esame le entities del modello ad oggetti appartenenti al namespace DotNetCircle.Rcd2.Common.ObjectModel sono contenute non solo nel progetto DotNetCircle.Rcd2.Common, ma anche nel progetto DotNetCircle.Rcd2.Business. In questo caso lo strato di business include entities che per esigenze di performance e scalabilità operano un caricamento dilazionato (Lazy Load) dei dati, invocando internamente funzionalità proprie dello strato di accesso ai dati. Questa necessità obbliga ad inserire alcune classi nel progetto DotNetCircle.Rcd2.Business, dal momento che il Business Logic Layer è l'unico strato in grado di interagire con il DAL.
Conclusioni
È indubbio che la realizzazione di una applicazione stratificata comporti un maggiore sforzo in termini di sviluppo rispetto ad un approccio, per così dire, meno strutturato. Tuttavia, come già affermato nel corso dell'articolo, il ricorso alla stratificazione, in particolar modo se abbinata all'uso di custom entities, comporta innumerevoli vantaggi in termini di manutenzione del codice, scalabilità, flessibilità e sicurezza.
A supporto dello sviluppo di applicazioni stratificate basate sul domain model, già oggi esistono soluzioni in grado di facilitare la vita ai developer e limitare i tempi di sviluppo. Gli ORM (Object/Relational Mapper), di cui NHibernate è il più diffuso e apprezzato, facilitano la creazione dello strato di accesso ai dati, anche e soprattutto nei casi più complessi, eliminando tutto il codice di plumbing destinato alla mappatura dei dati presenti nella sorgente dati con le entities del dominio applicativo. Del resto, anche tecnologie di prossima uscita come LINQ e l'Entity Framework vanno esattamente nella stessa direzione, incentivando e facilitando per le applicazioni data-centric l'adozione di soluzioni architetturali basate sul domain model, dal momento che forniscono un meccanismo evoluto di lettura delle informazioni sia in ambito BLL che DAL.
3 pagine in totale: <<Indietro 1 2 [3]
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Contenuti
Stampa 
Download
