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
Blog: http://www.codewrecks.com
Blog: http://blogs.ugidotnet.org/rgm
Mauro Servienti
Senior Software Architect @ Gaia
Microsoft MVP Visual C# / MCTS
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
Top Related