Dal requisito all'implementazione @ CD2010

1. Dal requisito all'implementazione
6 scenari «real world» e 6
soluzioni architetturali

2. Who we are
Gian Maria Ricci Mauro Servienti
Libero professionista @ me Senior Software Architect @ Gaia
Microsoft MVP Visual Studio ALM Microsoft MVP Visual C# / MCTS
@: alkampfer@nablasoft.com @: mauro.servienti@gaia.is.it
Blog: http://www.codewrecks.com Blog: http://milestone.topics.it
Blog: http://blogs.ugidotnet.org/rgm

3. 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;

4. Welcome to the machine…
INTERAZIONE UOMO -
MACCHINA

5. 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;

6. 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;

7. 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;

8. Schema di funzionamento

9. Interazione Uomo - Macchina
DEMO

10. The Postman always rings twice…
MESSAGING OVER WCF

11. Scenario
• Migrazione di un’applicazione a plug-in
Windows Forms esistente;
• Applicazione LOB Silverlight e back-end
basato su servizi WCF;

12. 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»;

13. 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)»;

14. Messaging over WCF
DEMO

15. Sfruttiamo Castle.Windsor per aumentare la flessibilità di
comunicazione
CREAZIONE DINAMICA DI
PROXY WCF

16. 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;

17. 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;

18. 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 

19. Schema di funzionamento

20. Creazione dinamica di Proxy WCF
DEMO

21. Nightmare before Christmas :-P
INTRODUCING I.O.C. IN WEB
FORMS

22. 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;

23. 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;

24. 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;

25. Introducing I.o.C. in Web Forms
DEMO

26. Fidarsi degli utenti è bene, ma non fidarsi è sicuramente meglio 
AUDIT DEI DATI

27. 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;

28. 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;

29. Audit dei dati
DEMO

30. Un requisito un po’ diverso dal solito…
QUERY SPECIFICATION VS
REPOSITORY OVER WCF

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

32. 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

33. «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;

34. 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?

35. Query Specification vs Repository over WCF
DEMO