6

È generalmente accettato che passare un container IoC attorno all'applicazione e utilizzarlo come un localizzatore di servizi sia una cattiva pratica.È possibile utilizzare uno stile di vita con scope nel Castello di Windsor senza far passare il contenitore?

Preferisco utilizzare il contenitore solo nella radice composita della mia applicazione e tendono a effettuare una singola chiamata a Resolve() - risolvere l'oggetto di livello superiore nella mia applicazione e rispondere sul contenitore per iniettare le dipendenze alle classi inferiori in il grafico dell'oggetto.

Castle Windsor ha recentemente aggiunto uno stile di vita ambito, in cui è possibile chiamare container.BeginScope() all'interno di un blocco "using". Dall'interno di questo blocco "using", la risoluzione di un componente che è stato registrato con uno stile di vita con ambito restituirà la stessa istanza ogni volta, per la durata del blocco "using".

container.Register(Component.For<A>().LifestyleScoped()); 

using (container.BeginScope()) 
{ 
    var a1 = container.Resolve<A>(); 
    var a2 = container.Resolve<A>(); 
    Assert.AreSame(a1, a2); 
} 

Domanda: Dato che BeginScope() è un metodo di estensione sul contenitore, non riesco a vedere come uno stile di vita ambito potrebbe essere utilizzato in un'applicazione a meno che il contenitore viene passato in giro (che ho davvero don' t voglio fare). Qualcuno ha qualche esempio di dove/come può essere usato lo stile di vita con scope?

Grazie,

Tom

+3

dove e come si prevede di utilizzare lo stile di vita con ambito? –

+0

Ciao Krzystof, non ho ancora intenzione di usare lo stile di vita con scope. Volevo solo vedere alcuni esempi di come lo stile di vita con scope può essere usato correttamente, nel caso in cui volessi usarlo in futuro. Immagino che usarlo all'interno delle fabbriche sia un approccio logico. –

+1

Questo sembra simile a quello che mi serve, non voglio risolvere le istanze con scope come dipendenze in costruttori, di oggetti con lo stesso scope: http://stackoverflow.com/questions/25064516/dependency-injection-lifestyle- service-shared-instance-between-2-instances-of –

risposta

7

penso che l'uso sarebbe tipicamente all'interno di una fabbrica, che non in genere arriva a vedere il contenitore. Pensa a un'applicazione web: in un certo senso, ogni chiamata di un controller in un'app MVC o una "pagina" sta eseguendo un programma semi-indipendente. Non è irragionevole che quel "programma" risolva le proprie dipendenze. Cioè, ogni chiamata del controller dovrebbe risolvere le sue dipendenze usando il contenitore.

Nell'ambito di una particolare richiesta Web, di una richiesta TCP o di una sessione utente, è possibile che il contenitore risolva gli oggetti in modo diverso. Questo è un modo per farlo in modo pulito all'interno di una delle tue fabbriche. Come per tutti gli usi di IoC, devi stare attento a non abusarne in modo tale che la logica di business finisca per intrufolarsi nel tuo codice di registrazione.

+1

Concordato. Dopo aver fatto ulteriori riflessioni e letture, il consenso generale sembra essere che il contenitore può essere utilizzato all'interno dell'assembly del punto di ingresso "la radice composita" (tramite installer/bootstrapper e factory), ma non deve "perdere" in altri assembly contenenti il dominio dell'applicazione. –