Con oggi ho finalmente terminato di scrivere l'applicazione per il Real Code Day. Compresi gli unit test, in tutto l'applicazione comprende 57 tipi suddivisi tra i diversi assembly. L'applicazione tratta la gestione di un ipotetico magazzino di prodotti hardware (monitor, stampanti, portatili, ecc.), con la necessità di gestire gli ordini provenienti da clienti e fornitori.

Quando sono partito con l'analisi e lo sviluppo ai primi di agosto, l'idea di fondo è stata quella di realizzare una applicazione three-layer applicando i principali design pattern previsti per le applicazioni di tipo enterprise. La scelta è ricaduta principalmente su Domain Model e Data Mapping. Gli altri pattern che in particolare ho usato sono: Special Case, Service Layer, DTO, Strategy (GOF).

Ecco alcune anticipazioni su quello che farò vedere a Firenze.

Domain Model: sono state individuate le entità (sia tipi concreti che tipi astratti), che implementano una interfaccia IEntity che contiene i metodi Equals() e IsValid(). Alcune delle entità derivano da classi base astratte di cui implemetano alcuni metodi/proprietà, altre sono sono direttamente tipi concreti. Anche se in generale sarebbe stato possibile utilizzare direttamente il tipo base come tipo concreto, in alcuni casi ho preferito derivare per avere un numero più ampio di casi da mostrare. Accanto alle entità, sono state create le collection tipizzate (usando come tipo degli item sempre e comunque i tipi base delle entità) che derivano da CollectionBase (che già di suo implementa ICollection, IEnumerable e IList). Nell'evento farò vedere come creare una entità e come creare una collection tipizzata per quella entità a partire dalla classe base CollectionBase. Accanto alle entità e alle collezioni, ho creato un Service Layer per la chiamata dei metodi esposti dal DAL, incapsulando la logica di creazione e invocazione degli oggetti per l'accesso ai dati e il cast dell'oggetto IEntity/IList al tipo concreto dell'entità/collection.

Data Mapping: nell'applicazione ho creato un oggetto astratto DataMapper che espone una interfaccia standard per i vari mapper dell'applicazione. Il mapper permette di incapsulare la logica di accesso ai dati contenuta nel caso in questione in una classe helper utile allo scopo. Al di fuori del mapper, nulla è noto circa l'implementazione della logica di accesso ai dati e sulla tipologia del data source. Sfruttando il pattern Strategy, ho cercato di incapsulare i mapper in un contesto che rappresentasse l'unico punto di contatto del DAL con il mondo esterno. Questo contesto di caricamento del mapper è un oggetto DataManager, che funge da wrapper per ogni singolo mapper e che usa IEntity e IList come tipi di ritorno. Esternamente al DAL non è possibile chiamare un mapper (i cui metodi sono tutti internal), ma solo l'istanza di DataManager che incapsula il mapper stesso. All'evento spiegerò questa architettura, facendo vedere come si applica lo Strategy, come si crea una classe Helper e come funziona il Data Mapping.

Considerazioni aggiuntive: ho evitato di utilizzare il Lazy Load per non buttare troppa carne sul fuoco. In ogni caso nel mapper ho creato dei meccanismi di caricamento parziale degli oggetti per risparmiare memoria. Il metodo IsValid() di IEntity serve proprio a questo. Non ho utilizzato alcun tipo di chiamata transazionale, sempre per evitare di complicare ulteriormente la cosa. Avendo solo un'ora a disposizione per mostrare il tutto, troppa complessità avrebbe rappresentato un problema più che un valore aggiunto.

Database: lo schema (molto semplice e lineare) prevede 8 tabelle e ben 40 stored procedure, una per ogni metodo associato ai mapper. Niente transazioni anche qui, ma codice T-SQL molto semplice e pulito...

Testing e analisi del codice: tutti gli assembly principali (che sono tre) sono stati sottoposti a FxCop, risultando pienamente conformi. Sia da un punto di vista di nomenclatura che di strutturazione del codice, ho posto particolare attenzione alla forma applicando tutte le regole valide per la scrittura di codice pulito. FxCop mi è testimone! Parallelamente ho creato 16 classi di test per un totale di 64 unit test. Inutile dire che ho rilasciato solo a fronte di un "verde" generalizzato...

Spero di aver suscitato il vostro interesse circa i contenuti della mia prossima sessione al Real Code Day. Pertanto spero di incontrarvi a Firenze il 26 ottobre p.v. per scambiare due chiacchiere in allegria e (perchè no!) per scambiarsi idee e opinioni anche di natura tecnica.

Mi raccomando: iscrivetevi!!! Lo potete fare sul sito di DotNetCircle.it o sul sito di MSDN Italia.