6

En general, se acepta que pasar un contenedor IoC alrededor de su aplicación y usarlo como un localizador de servicios es una mala práctica.¿Es posible utilizar un estilo de vida delimitado en Castle Windsor sin pasar el contenedor?

Prefiero usar el contenedor solo en la raíz compuesta de mi aplicación y tiendo a hacer una sola llamada a Resolve() - resolviendo el objeto de nivel superior en mi aplicación y respondiendo en el contenedor para inyectar dependencias a clases inferiores en el gráfico de objetos

Castle Windsor ha agregado recientemente un estilo de vida con ámbito, donde puede llamar a container.BeginScope() dentro de un bloque "using". Desde dentro de este bloque "usar", la resolución de un componente que se registró con un estilo de vida delimitado devolverá la misma instancia cada vez, durante la duración del bloque "usar".

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

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

Pregunta: Dado que BeginScope() es un método de extensión en el envase, no veo cómo un estilo de vida con ámbito podría ser utilizado en una aplicación a menos que el recipiente se pasa alrededor (que realmente don' quiero hacer). ¿Alguien tiene algún ejemplo de dónde/cómo se puede usar el estilo de vida de alcance?

Gracias,

Tom

+3

¿dónde y por qué planea utilizar el estilo de vida de ámbito? –

+0

Hola, Krzystof, aún no tengo planes de utilizar el estilo de vida de alcance. Solo quería ver algunos ejemplos de cómo se podría usar el estilo de vida correctamente, en caso de que quisiera usarlo en el futuro. Supongo que usarlo dentro de las fábricas parece un enfoque lógico. –

+1

Esto parece similar a lo que necesito, quiero resolver instancias con ámbito como dependencias en constructores, de objetos con en el mismo ámbito: http://stackoverflow.com/questions/25064516/dependency-injection-lifestyle- service-shared-instance-between-2-instances-of –

Respuesta

7

creo que el uso sería típicamente en el interior de una fábrica, lo que por lo general llega a ver el contenedor. Piense en una aplicación web: en cierto sentido, cada invocación de un controlador en una aplicación MVC, o una "página", ejecuta un programa semiindependiente. No es irrazonable que ese "programa" resuelva sus propias dependencias. Es decir, cada invocación de controlador debería resolver sus dependencias utilizando el contenedor.

En el ámbito de una solicitud web particular, o una solicitud TCP, o una sesión de usuario, es posible que desee que el contenedor resuelva los objetos de forma diferente. Esta es una forma para que lo haga limpiamente dentro de una de sus propias fábricas. Al igual que con todos los usos de IoC, debe tener cuidado de no abusar de tal manera que la lógica de negocios termine infiltrándose en su código de registro.

+1

De acuerdo. Después de pensar un poco más, el consenso general parece ser que el contenedor puede usarse dentro del ensamblaje del punto de entrada "la raíz compuesta" (a través de instaladores/iniciadores y fábricas), pero no debe "filtrarse" en otros ensambles que contengan dominio de aplicación. –

Cuestiones relacionadas