Post

Visualizzazione dei post da marzo, 2013

Inversion of Control e Dependecy Injection fatti in casa (3)

Finalmente siamo giunti all'ultimo capitolo della saga iniziata con i precedenti due post riguardanti l'introduzione all'IoC e l'implementazione dei plugins ; finalmente siamo giunti al nocciolo della questione; finalmente, senza indugio, passiamo a vedere qualche cosa di interessante... Il pezzo che manca a completare il puzzle è capire come dare la possibilità alla nostra applicazione di generare un'istanza di un particolare oggetto, che implementa l'interfaccia "IFinder", utilizzando una semplice stringa di testo. La struttura che permette la "magia" è la classe statica "FinderIoc", e il suoo metodo "CreateProvider". Come visto in precedenza, l'utilizzo della stessa è estremamente banale; l'implementazione nasconde qualche piccola insidia, dovendo fare uso di tecniche quali "Activation", "Reflection" e "Dynamic Type Generation". Dopo una sana validazione dell'argomento in

Inversion of Control e Dependecy Injection fatti in casa (2)

Nella precedente puntata eravamo rimasti alla descrizione del service layer di accesso alle funzionalità applicative. Inoltre, la definizione dell'interfaccia "IFinderProvider" permette di esporre il contratto condiviso tra i differenti plugin di ricerca: share, local e webservice. Come detto, prima di passare alla descrizione del "container", responsabile della gestione modulare operata da Dependency Injection, vediamo l'implentazione reale del modulo "Local". Il codice riportato è una banalissima implementazione di "mockup" che emette dei sample data. In una situazione reale la logica applicativa eseguirebbe una ricerca sul disco locale, magari scansionando le directoy secondo una struttura definita, e partendo da un percorso "radice" definito da configurazione applicativa. La cosa importante è che il modulo "Local" è implementato dalla classe "LocalFinderProvider", che rispetta i termini del contratt