Dal requisito all'implementazione @ CD2010

Dal requisito all'implementazione

6 scenari «real world» e 6 soluzioni architetturali

Who we are

Gian Maria Ricci

Libero professionista @ me

Microsoft MVP Visual Studio ALM

@: [email protected]

Blog: http://www.codewrecks.com

Blog: http://blogs.ugidotnet.org/rgm

Mauro Servienti

Senior Software Architect @ Gaia

Microsoft MVP Visual C# / MCTS

@: [email protected]

Blog: http://milestone.topics.it

Gli Scenari

• Interazione Uomo - Macchina;• Messaging over WCF;• Creazione dinamica di Proxy WCF;• Introducing I.o.C. in Web Forms;• Audit dei dati;• Query Specification vs Repository;

INTERAZIONE UOMO - MACCHINA

Welcome to the machine…

Scenario• Il nostro software deve gestire gli

input/output di un macchinario;

• Tutte le logiche applicative sono fatte nel

software, il macchinario ha solo bottoni, leve e segnalatori luminosi;

Requirements• Il software dialoga con un macchinario su

cui opera un utente;• Il Product Owner vuole come requisito la

possibilità di nominare uno o più «Domain Expert» che dovranno testare le logiche che guidano la macchina;

• Il product owner vorrebbe automatizzare alcuni dei test che verificano le nostre logiche;

Solution• La soluzione migliore è quella di

disaccoppiare l’accesso all’hardware tramite logica «plugin»;

• In questo modo le logiche applicative dipendono da una IMachine la quale comunica con un IHardwareController;

• In questo modo è possibile realizzare una interfaccia che simula la macchina e quindi usare MTM e Coded UI Test;

Schema di funzionamento

DEMOInterazione Uomo - Macchina

MESSAGING OVER WCFThe Postman always rings twice…

Scenario

• Migrazione di un’applicazione a plug-in Windows Forms esistente;

• Applicazione LOB Silverlight e back-end basato su servizi WCF;

Requirements

• Supporto per un sistema a plug-in:– server side e client side;– Serializzazione e/o Parallelizzazione;

• Supporto per installazioni in configurazioni diverse;

• Supporto per versioning «non sincrono»;

Solution

• Sfruttare la vera natura di WCF: i messaggi;

• Il server espone solo due metodi:– void Broadcast( OneWayOperation );– Response Dispatch( TwoWayOperation );

• Client-side e Server-side «iniettiamo» «Messagge(s)» e «MessageHandler(s)»;

DEMOMessaging over WCF

CREAZIONE DINAMICA DI PROXY WCF

Sfruttiamo Castle.Windsor per aumentare la flessibilità di comunicazione

Scenario

• Applicativo WCF/Winform/Desktop che viene utilizzato internamente da una ditta con accesso al database locale;

• Lo stesso software può essere dato in uso a clienti esterni che non hanno chiaramente accesso diretto al database;

• Non si vuole mettere i clienti esterni in vpn;

Requirements

• Si vuole che il software sia deployabile in due configurazioni;

• La prima interna in cui l’accesso viene fatto direttamente al database in rete locale;

• La seconda per i clienti esterni che accederanno tramite un servizio WCF;

Solution

• Il ViewModel Dipenderà da vari servizi come IMusicStore service;

• Nella configurazione interna si risolve con castle una classe MusicStore che accede al db internamente;

• Nella versione esterna realizziamo una facility di Castle.Windsor che crea «on the fly» il proxy ai servizi wcf;

• Basta cambiare il config ed è fatta

Schema di funzionamento

MusicStoreService

MusicStoreService ProxyWCF

DEMOCreazione dinamica di Proxy WCF

INTRODUCING I.O.C. IN WEB FORMS

Nightmare before Christmas :-P

Scenario

• Applicazione web legacy, molto legacy, basata su Web Form;

• CMS basato su «componenti» (aka ascx);

• Svariate decine di installazioni con supporto per l’auto-update;

Requirements

• Necessità di aggiornare la metodologia di sviluppo dei nuovi componenti introducendo, tra le tante, IoC;

• Necessità di mantenere la retro-compatibilità con tutte le installazioni esistenti;

Solution

• Al fine di avere IoC dobbiamo inizializzare il container allo startup, quindi niente HttpModule ma modifica al global.asax;

• «ISupportInitialize» al fine di ridurre a zero le breaking change:– Nessuna nuova dipendenza;– Eccezioni soffocate e «semplicemente»

loggate;• Le nuove «Web Form» diventano dei meri

«passacarte» tra la view e i servizi;

DEMOIntroducing I.o.C. in Web Forms

AUDIT DEI DATIFidarsi degli utenti è bene, ma non fidarsi è sicuramente meglio

Requirements• Alcune Entità/Tabelle, ma non tutte,

potrebbero in futuro dovere essere auditabili;

• Per «auditabile» si intende la possibilità di determinare chi e quando ha creato la riga/istanza e chi e quando ha apportato l’ultima modifica;

Soluzione • Adottare un ORM permette di intercettare

ogni «save» e «update» delle entità;• In questo modo l’operazione di audit può

essere centralizzata e resa trasparente allo sviluppatore;

• Per rendere una entità auditabile è sufficiente aggiungere le proprietà e la corrispettiva interfaccia;

DEMOAudit dei dati

QUERY SPECIFICATION VS REPOSITORY OVER WCF

Un requisito un po’ diverso dal solito…

Scenario

• Servizio WCF per la gestione di un «albero»:– Rami;– Foglie;– Attributi (sia su rami che su foglie);

Requirements

• I dati gestiti dall’albero devono essere localizzabili;

• Esporre un motore di «query» over WCF;

• Introdurre nel team un dev junior:– completamente a digiuno di WCF…;– …e anche di tutto il resto :-P

«Tentative»

• il «repository» è stato fallimentare:– Per il dev junior troppo difficile da

maneggiare;– Inutilmente complesso cercare di gestire il

concetto di «query componibile»;– Proliferare di metodi intellisense pollution;– Necessità di necessità di condividere tra

repository diversi la stessa UoW;

Solution

• «Query Specification»– Classe che astrae il concetto di query;– Classe che si occupa di eseguire la query a

fronte di un provider;– UoW condivisa in base al caso d’uso;

• «Query Criteria» over WCF:– Cosa ci vieta di rappresentare con dei DTO il

concetto di «criterio» e renderlo componibile?

DEMOQuery Specification vs Repository over WCF

Technology

Dal requisito all'implementazione @ CD2010