SlideShare a Scribd company logo

Inversion of Control @ CD2008

•Download as PPTX, PDF•
•
Mauro Servienti
Mauro Servienti

Inversion of Control @ CD2008

Related slideshows

m-v-vm @ UgiAlt.Net
m-v-vm @ UgiAlt.Netm-v-vm @ UgiAlt.Net
m-v-vm @ UgiAlt.Net
 
Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con DelphiDelphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
 
Brokering over WCF @ dotNetMarche
Brokering over WCF @ dotNetMarcheBrokering over WCF @ dotNetMarche
Brokering over WCF @ dotNetMarche
 
1 of 34
Realizzare applicazioni estendibili e configurabili Ambizioso? Mauro Servienti Microsoft MVP - Visual C# Software Mason @ Managed Designs S.r.l. mauro.servienti@manageddesigns.it
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;
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”;
Perchè abbiamo bisogno di realizzare applicazioni estensibili. ESTENSIBILITÀ... WHO CARES?
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;
Un primo approccio al problema LE DIPENDENZE STATICHE
il problema: le dipendenze statiche Componente Componente ComA ComB
Il cammino verso la soluzione... Componente Interfaccia ComA IComB Componente ComB ...to be continued
Fobia da “dipendenza statica”?, un faro nella nebbia... I PRINCIPI GUIDA
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;
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”;
Non “Closed”
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;
Troppe responsabilità
Il panico da “Empty Solution” BEST PRACTICE(S)
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;
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;
Il meglio dei due mondi (1)
Il meglio dei due mondi (2) ...to be continued
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”
Mascheriamo
...ma dietro le quinte? • Slega il nostro modello da Asp.Net; – Siamo “Open”!; • Quanto abbiamo investito?
Prevedere... • Non abbiamo la sfera di cristallo • Incapsulare i dati in classi adatte al loro trasporto: – EventArgs; – CancelEventArgs; – CustomEventArgs : estendiamo CancelEventArgs/EventArgs
“Trasportare” i dati • le informazioni non sono sufficienti • ...non compila più: non siamo “Closed”
Le “pipeline” • “pipeline”, un esempio da seguire: – HttpModule + HttpHanlder; Request IProcessor IProcessor IProcessor IProcessor A B C n Data
Le “pipeline” (code)
Inversion of Control Interfaccia Componente ServiceProvider ComA (IoC Container) IComB Componente IoC ComB Config
Vediamolo in azione.... DEMO
IoC Containers e non solo • StructureMap; • Castle Windsor; • Spring.NET • Unity (Enterprise Library 4.0)
I’ve got the power <cit.> • Se volessimo cambiare l’ordine...? • Se volessimo aggiungere/rimuovere step...? • Se volessimo fare il tutto “a caldo”...?
Vediamolo in azione.... DEMO
IoC Containers: cosa offrono • Contenitore di Servizi; • Lifecycle management; • Policy Injection (interceptors); • Difetti? Si la gestione della configurazione...
Non sparate sul pianista.... DOMANDE?
Grazie a tutti, mi raccomando... IL MODULO DI FEEDBACK

More Related Content

Inversion of Control @ CD2008

  • 1. Realizzare applicazioni estendibili e configurabili Ambizioso? Mauro Servienti Microsoft MVP - Visual C# Software Mason @ Managed Designs S.r.l. mauro.servienti@manageddesigns.it
  • 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. 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. Perchè abbiamo bisogno di realizzare applicazioni estensibili. ESTENSIBILITÀ... WHO CARES?
  • 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. Un primo approccio al problema LE DIPENDENZE STATICHE
  • 7. il problema: le dipendenze statiche Componente Componente ComA ComB
  • 8. Il cammino verso la soluzione... Componente Interfaccia ComA IComB Componente ComB ...to be continued
  • 9. Fobia da “dipendenza statica”?, un faro nella nebbia... I PRINCIPI GUIDA
  • 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. 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”;
  • 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;
  • 15. Il panico da “Empty Solution” BEST PRACTICE(S)
  • 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. 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. Il meglio dei due mondi (1)
  • 19. Il meglio dei due mondi (2) ...to be continued
  • 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”
  • 22. ...ma dietro le quinte? • Slega il nostro modello da Asp.Net; – Siamo “Open”!; • Quanto abbiamo investito?
  • 23. Prevedere... • Non abbiamo la sfera di cristallo • Incapsulare i dati in classi adatte al loro trasporto: – EventArgs; – CancelEventArgs; – CustomEventArgs : estendiamo CancelEventArgs/EventArgs
  • 24. “Trasportare” i dati • le informazioni non sono sufficienti • ...non compila più: non siamo “Closed”
  • 25. Le “pipeline” • “pipeline”, un esempio da seguire: – HttpModule + HttpHanlder; Request IProcessor IProcessor IProcessor IProcessor A B C n Data
  • 27. Inversion of Control Interfaccia Componente ServiceProvider ComA (IoC Container) IComB Componente IoC ComB Config
  • 29. IoC Containers e non solo • StructureMap; • Castle Windsor; • Spring.NET • Unity (Enterprise Library 4.0)
  • 30. I’ve got the power <cit.> • Se volessimo cambiare l’ordine...? • Se volessimo aggiungere/rimuovere step...? • Se volessimo fare il tutto “a caldo”...?
  • 32. IoC Containers: cosa offrono • Contenitore di Servizi; • Lifecycle management; • Policy Injection (interceptors); • Difetti? Si la gestione della configurazione...
  • 33. Non sparate sul pianista.... DOMANDE?
  • 34. Grazie a tutti, mi raccomando... IL MODULO DI FEEDBACK