8

I have 4 progetti:Dependency Injection e progetto di struttura per le applicazioni console

core (iServer):

  • sistema
  • System.Core

DependencyResolver:

  • Nucleo
  • StructureMap

Infrastructure (Servizio):

  • Nucleo
  • dipendenza esterna

Console:

  • Nucleo
  • DependencyResolver

requierements:

Sto cercando di utilizzare StructureMap solo nel DependencyResolver. Inoltre l'applicazione Console non dovrebbe sapere nulla di Infrastucture.

Quando non desidero fare riferimento a StructureMap sulla mia applicazione Console, devo creare un ServiceLocator.

Nel DependencyResolver Ho un programma di avvio automatico che è responsabile per la chiamata roba registro StructureMap (Registrati)

Nella mia applicazione Console voglio ottenere un'istanza. Per questo ho bisogno di fare riferimento a StructureMap. Un altro modo sarebbe scrivere un piccolo wrapper attorno ai metodi di risoluzione di StructureMaps.

C'è qualche altro modo migliore per disaccoppiare la console da StructureMap?

+0

Sembra un po 'troppo ingegnoso. Com'è il tuo codice? Perché hai bisogno di un localizzatore di servizi se il tuo risolutore di dipendenze incapsula già la mappa della struttura? – SimonC

+0

Hai visto http://bootstrapper.codeplex.com/ –

+0

Il risolutore di dipendenze nome non è la scelta migliore in relazione a ciò per cui il componente è responsabile. Al momento la sua unica responsabilità è registrare le dipendenze. Quindi la mia domanda riguarda più la parte risolutiva di Dipendenza Iniezione. – Rookian

risposta

17

Mentre vedo un motivo per separare il registro IoC, risolvere, rilasciare dall'implementazione dell'applicazione, non vedo alcuna ragione per cui il contenitore IoC non dovrebbe essere nell'applicazione console (la radice di composizione) e il implementazione dell'applicazione in un altro assembly.

In questo modo l'applicazione console è molto semplice:

  1. creare il contenitore
  2. Caricare la configurazione del contenitore
  3. Risolvere l'applicazione
  4. chiamata corsa sulla domanda e passare gli argomenti della console insieme
  5. smaltire il contenitore quando l'applicazione esce dal metodo di esecuzione

Con SM apparire su come questo:

public void Main(params string[] args) 
{ 
    using (var container = new Container()) 
    { 
     container.LoadAllConfigurationModules(); 
     container.AddRegistry<SomeRegistry>(); 
     container.GetInstance<Application>().Run(args); 
    } 
} 

Per cose che non si possono creare in fase di avvio si crea un'interfaccia fabbrica in vostra assemblea applicazione:

interface ISomeFactory { ISomeDependency CreateSomeDependency() } 

e implementare questa interfaccia in applicazione console iniettando il contenitore e utilizzarlo per risolvere l'istanza. Credo che l'attuazione SM è simile al seguente:

public class SomeFactory : ISomeFactory 
{ 
    public SomeFactory(IContainer sontainer) { this.container = container; } 
    ISomeDependency CreateSomeDependency() { this.container.GetInstance<ISomeDependency>(); } 
} 

altro contenitore CIO nemmeno la functionallity implementare automaticamente queste fabbriche di interfaccia.

+0

Con la tua soluzione devi fare riferimento a tutte le librerie nell'applicazione console. Perché la radice della composizione si trova direttamente nella classe Main. – Rookian

+6

Sì, è corretto. Ma dov'è il problema? Questo assemblaggio ha esattamente uno scopo: il bootstrap! –

+0

ah ok. La tua seconda affermazione è importante. Ciò ha senso. – Rookian

Problemi correlati