2013-04-20 21 views
7

Recentemente, ho cercato di capire qual è la differenza tra l'uso del localizzatore di servizi" anti-pattern "e l'utilizzo del Castle Windsor container Ho trovato alcune informazioni qui e là su Internet e ho riassunto quello che ho imparato finora in an unfinished blog post.Qual è la differenza tra l'utilizzo dell'anti-pattern di Service Locator e l'utilizzo del contenitore Castle Windsor? "

EDIT: Fino ad ora ho pensato che l'iniezione di dipendenza è tutto ciò che sarebbe necessario per garantire la separazione. Ma ovunque guardo, vedo una spinta nella direzione di contenitori come il Castello Windsor, vorrei capire chiaramente i motivi. Per favore ... Explain this to me like I'm a 6 year old :)

+0

Quale software hai utilizzato per i tuoi diagrammi? – devdigital

+1

yUML: http://yuml.me/ –

+2

Ho tentato di rispondere a questa domanda qui: http://blog.ploeh.dk/2011/08/25/ServiceLocatorrolesvs.mechanics –

risposta

17

Divertente, dovresti chiedere di spiegarlo come se avessi sei anni; ecco un explanation like you were five years old :)

ovunque guardo vedo una spinta nella direzione di contenitori, come il Castello di Windsor

Francamente, penso che la ragione di ciò è che la maggior parte delle persone in realtà non capiscono cos'è Dependency Injection, il che significa che invece di cogliere il concetto di Inversion of Control, vanno alla ricerca di un sostituto della parola chiave new a cui sono già abituati. Quindi trovano un contenitore DI e (errano) lo usano come localizzatore di servizio. Sfortunatamente, è molto facile da fare.

Questo è il motivo per cui, in my book, spiego tutti i concetti DI senza accoppiare la spiegazione a nessun singolo contenitore DI. Questa è in realtà la maggior parte del libro.

Service Locator e Dipendenza iniezione sono two fundamentally different attempts at achieving loose coupling. Service Locator presenta molti svantaggi e non offre vantaggi non offerti da DI. Questo è il motivo per cui penso che chiamare il localizzatore di servizi sia un anti-modello sicuro.

Non è necessario un contenitore DI per utilizzare DI; infatti, direi che unless you take a rather sophisticated approach, it's probably better to avoid one.

+0

@MichaelKohne Siamo spiacenti, è stato risolto ora. –

3

Bene, un localizzatore di servizi può essere solo un involucro attorno a una particolare inversione di container di controllo come Castle Windsor. Il punto è che l'unico posto in cui il codice dovrebbe (idealmente) fare riferimento al contenitore è sul tuo composition root.

Poiché l'inversione dei contenitori di controllo supporta il concatenamento delle dipendenze, quando si risolve il tipo di root dal contenitore, verranno iniettate tutte le sue dipendenze e tutte le dipendenze discendenti.

Se si desidera quindi creare altri tipi in fase di esecuzione, è possibile utilizzare le fabbriche, che potrebbero anche avere un riferimento al contenitore se si desidera sfruttare il concatenamento di dipendenze offerto dal contenitore e le mappature del contenitore di interfacce contro implementazioni.

3

Quando si utilizza il localizzatore di servizi, il proprio codice chiama localizzatore per servizi ovunque. Quando si utilizza l'inversione del controllo, c'è solo una posizione (radice della composizione), in cui si chiama contenitore. Il resto della tua app non dovrebbe essere a conoscenza del contenitore.

+0

Quando hai detto "contenitore consapevole" intendevi "inconsapevole"? – Charleh

+0

ups "non dovrebbe essere consapevole del contenitore" :) –