Inversion of Control @ CD2008

546 views

Published on

Inversion of Control @ CD2008

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
546
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Inversion of Control @ CD2008

  1. 1. Realizzare applicazioniestendibili e configurabili Ambizioso? Mauro Servienti Microsoft MVP - Visual C# Software Mason @ Managed Designs S.r.l. mauro.servienti@manageddesigns.it
  2. 2. Agenda• Perchè?• Il “problema”;• Dogmi: – Open Closed Principle; – Single Point of Responsability;• Best Practice(s);• Inversion Of Control;• Chain Of Responsability;• Una voce fuori dal coro: System.AddIn;
  3. 3. IMHO• La bacchetta magica non esiste: – Ogni volta è una nuova avventura; – Non c’è una ricetta che vada bene per tutte le salse ;-) – Esistono i Design Pattern....ma...• Partire dai Pattern è rischioso: – Rischia di farci perdere la visione concreta del progetto; – Refactoring to Pattern: “software mason”;
  4. 4. Perchè abbiamo bisogno di realizzare applicazioni estensibili.ESTENSIBILITÀ... WHOCARES?
  5. 5. Perchè?• Supporto per l’integrazione e l’interoperabilità;• Consente di modificare a caldo il comportamento;• Elevatissima manutenibilità;• Verticalizzazione;• Testing;• Può essere un’ottimo “strumento” commerciale;
  6. 6. Un primo approccio al problemaLE DIPENDENZE STATICHE
  7. 7. il problema: le dipendenze statiche Componente Componente ComA ComB
  8. 8. Il cammino verso la soluzione...Componente InterfacciaComA IComB Componente ComB ...to be continued
  9. 9. Fobia da “dipendenza statica”?, un faro nella nebbia...I PRINCIPI GUIDA
  10. 10. Open Closed Principle “software entities should be open for extension, but closed for modification”• Open for Extension: – Il componente deve essere estendibile;• Closed for Modification: – L’estensione non deve portare ad una rottura del rapporto;
  11. 11. Ma in soldoni?• Quello che vogliamo evitare è che una semplice modifica in un punto si propaghi a macchi d’olio in tutta l’applicazione; – Eg: sostituibilità a “caldo” del DAL • Se abbiamo un riferimento al DAL concreto non siamo “Closed”; • Se facciamo assunzioni particolari non siamo “Closed”;
  12. 12. Non “Closed”
  13. 13. Single Point of Responsability• Ad ognuno il suo ruolo;• Lo scope del ruolo assegnato deve essere il più preciso possibile (focuse);• Se ad un componente assegno più responsabilità violo l’Open Closed Principle;
  14. 14. Troppe responsabilità
  15. 15. Il panico da “Empty Solution”BEST PRACTICE(S)
  16. 16. Scrivere in ottica estensibilità• Interfaces vs. Abstract classes;• Pensare agli entry point;• Prevedere quali dati potranno essere necessari;• Le “pipeline”, un esempio da seguire: – HttpModule, HttpHanlder;• Refactoring, refactoring, refactoring, refactoring e ancora refactoring;
  17. 17. Interfaces vs. Abstract classes Interface Abstract Class • Posso simulare • Mi permette di fornire ereditarietà multipla; un’implementazione di • Non “brucio” l’unico punto base alle classi derivate; di inheritance Quindi?• Colgo il meglio dei due mondi: • Interface verso il chiamante; • Abstract Class(es) nel modello;
  18. 18. Il meglio dei due mondi (1)
  19. 19. Il meglio dei due mondi (2) ...to be continued
  20. 20. Entry Point• Dove avrò bisogno di estendere: – Ovunque ;-), mai chiudersi le porte...• Un esempio: la “Conversazione” – è la Session? Si; – Perchè non usare la Session? E se domani mattina la Session non mi andasse più bene? – Mettiamo le mani avanti: “Facade”
  21. 21. Mascheriamo
  22. 22. ...ma dietro le quinte?• Slega il nostro modello da Asp.Net; – Siamo “Open”!;• Quanto abbiamo investito?
  23. 23. Prevedere...• Non abbiamo la sfera di cristallo• Incapsulare i dati in classi adatte al loro trasporto: – EventArgs; – CancelEventArgs; – CustomEventArgs : estendiamo CancelEventArgs/EventArgs
  24. 24. “Trasportare” i dati• le informazioni non sono sufficienti• ...non compila più: non siamo “Closed”
  25. 25. Le “pipeline”• “pipeline”, un esempio da seguire: – HttpModule + HttpHanlder; Request IProcessor IProcessor IProcessor IProcessor A B C n Data
  26. 26. Le “pipeline” (code)
  27. 27. Inversion of Control Interfaccia Componente ServiceProvider ComA (IoC Container) IComB Componente IoC ComB Config
  28. 28. Vediamolo in azione....DEMO
  29. 29. IoC Containers e non solo• StructureMap;• Castle Windsor;• Spring.NET• Unity (Enterprise Library 4.0)
  30. 30. I’ve got the power <cit.>• Se volessimo cambiare l’ordine...?• Se volessimo aggiungere/rimuovere step...?• Se volessimo fare il tutto “a caldo”...?
  31. 31. Vediamolo in azione....DEMO
  32. 32. IoC Containers: cosa offrono• Contenitore di Servizi;• Lifecycle management;• Policy Injection (interceptors);• Difetti? Si la gestione della configurazione...
  33. 33. Non sparate sul pianista....DOMANDE?
  34. 34. Grazie a tutti, mi raccomando...IL MODULO DI FEEDBACK

×