Contenitori IoC e pattern localizzatore di servizio

Naviga le tue risposte
4

Sto cercando di capire l'Inversion of Control e i dos e donts di questo. Di tutti gli articoli che ho letto, c'è uno di Mark Seemann (a cui è ampiamente collegato SO) che chiede strongmente alla gente di non utilizzare il modello di localizzazione del servizio.

Poi, da qualche parte lungo la strada, mi sono imbattuto in questo articolo di Ken dove ci aiuta a costruire il nostro IoC personale.

Ho notato che non è altro che un'implementazione del modello di localizzazione del servizio.

Domande:

  1. La mia osservazione è corretta sul fatto che questa implementazione è il modello del localizzatore di servizi?
  2. Se la risposta a 1. è sì, allora tutti i contenitori IoC (come Autofac) usano il modello di localizzazione del servizio?
  3. Se la risposta a 1. è no, allora perché questo differen?
  4. C'è qualche altro schema (diverso da DI) per l'inversione del controllo?

Consolidamento delle risposte:

Rispondi 1. Kelly : il pattern di localizzazione del servizio viene effettivamente utilizzato per la chiamata di risoluzione iniziale. Il pattern del localizzatore di servizi deve essere utilizzato almeno una volta.

Risposta 2. Eric : Chiamare semplicemente Ioc.Resolve (ISomeInterface) non significa che il Il contenitore IoC viene utilizzato come localizzatore di servizi. Dopotutto, Resolve () deve essere chiamato da qualche parte, giusto?

Risposta 3. Tungano : No, il suo codice contiene un costruttore che riceve una dipendenza ... No, un il contenitore non "usa" alcun motivo. Dipende davvero dal programmatore che usa il contenitore per usare un modello. È tutto nel modo in cui lo si collega. Fondamentalmente puoi usare entrambi un contenitore per DI e Localizzatore di servizio.

Risposta 4. Gnat : ... fabbrica e ricerca ... [può essere utilizzato per l'inversione di controllo.]

Ho imparato, grazie alle risposte di cui sopra, che IoC stesso utilizza il Service Locator Pattern. Questo non è intrinsecamente dannoso. L'utilizzo di IoC può essere fatto in diversi modi (incluso il modello di localizzazione del servizio). Questa è la parte di cui abbiamo bisogno di fare attenzione e utilizzare altre opzioni di iniezione della dipendenza.

    
posta TheSilverBullet 11.12.2012 - 09:50
fonte

2 risposte

8

Il semplice richiamo di Ioc.Resolve(ISomeInterface) non significa che il contenitore IoC sia utilizzato come localizzatore di servizi. Dopotutto, Resolve() deve essere chiamato da qualche parte , giusto?

L'indizio è dove e quante volte è chiamato IoC.Resolve() ? Se viene chiamato dappertutto, negli stessi oggetti dipendenti, significa che il contenitore IoC viene utilizzato in modo errato come Localizzatore di servizi. Se Resolve() viene chiamato in una posizione centrale (in genere chiamata 'composizione root'), è probabile che venga utilizzato correttamente.

L'articolo che hai menzionato non parla di quando e dove chiamare Resolve() , spiega solo cosa succede dopo che è stato chiamato.

    
risposta data 12.12.2012 - 22:38
fonte
1

1) No, il suo codice contiene un costruttore che riceve una dipendenza: 

public BuildDirectoryStructureService(IFileSystemAdapter fileSystemAdapter)

Il contenitore IoC sta iniettando la dipendenza.

Se utilizzava il localizzatore di servizi, BuildDirectoryStructureService otterrebbe automaticamente la dipendenza. Ad esempio: 

public BuildDirectoryStructureService()
{
   this.fileSystemAdapter = Locator.Current.Resolve<IFileSystemAdapter>();
}

Un contenitore IoC può essere utilizzato come localizzatore di servizio.

2 & 3)

No, un contenitore non "usa" alcun motivo. Dipende davvero dal programmatore che usa il contenitore per usare un modello. È tutto nel modo in cui lo colleghi.

Fondamentalmente puoi usare entrambi un contenitore per DI e Localizzatore di servizio.

4) Si può fare l'iniezione del costruttore e ancora non si ha realmente l'inversione del controllo. Puoi chiedere tipi concreti in un costruttore. Le dipendenze iniettate potrebbero non avere un'astrazione praticabile per implementazioni multiple e simili.

L'inversione del controllo è allineata al principio principio di Hollywood , non chiamarci, noi Ti chiamerò. Invece di attivare un servizio, il servizio ti "richiama" su un'interfaccia che definisce.

    
risposta data 12.12.2012 - 21:57
fonte

Leggi altre domande sui tag

definizione di funzione non vista / sconosciuta in linux source TypeScript o JavaScript per sviluppatore web noob [chiuso]