dependencies - injection - ¿Inyectando su contenedor IoC?

laravel dependency injection controller

Question

Estuve investigando toda la mañana tratando de encontrar las mejores prácticas para acceder a su IoC. Después de agregar la inyección de constructor a sus clases, aún necesita acceder al contianer desde las clases que podrían estar en el fondo de su gráfico de objetos de aplicaciones. En mi caso, estoy haciendo MVVM en WPF y algunos de mis modelos de vista necesitan crear otros modelos de vista y usarían el contenedor para hacerlo. Pero la pregunta es de dónde sacar el contenedor. ¿Tiene sentido inyectarlo y pasarlo? ¿Está bien hacer que sea un singleton inyectable? ¿Es una fábrica que sirve un singleton más appropraite?

¿Cuáles son las opciones y las compensaciones?

Actualizar

Encontré esta gran charla de Matt Hinze que cubre mucho terreno de IoC: http://www.drowningintechnicaldebt.com/ShawnWeisfeld/archive/2010/04/08/inversion-of-control-in-action-by-matt- hinze-north.aspx

Parece que una respuesta es usar la función de escaneo y almacenar las configuraciones de IoC en los registros en cada ensamblaje y luego, durante la escaneación, se agregarán esas configuraciones de registro.

¿Hay otros enfoques a considerar? Especialmente considerando que Matt demostró usar el patrón ServiceLocator mientras que Mark Seeman llama a esto un anti-patrón. Tenga en cuenta que Matt advirtió sobre el uso excesivo del patrón y que la definición de Mark del Localizador de servicios (http://blog.ploeh.dk/Trackback.aspx?guid=5f05c086-295b-41e5-a50a-ed0cd77ac4bd) parece diferente de lo que Matt demostró .

Answer 1

En lugar de inyectar tus instancias reales de ViewModel, lo cual será difícil, como dices, puedes inyectar fábricas a tus ViewModels superiores. Es algo así como el patrón del localizador de servicios; es de esperar que las fábricas (o los proveedores de servicios, o lo que sea) sean más específicas en lo que pueden ofrecer.

Answer 2

Una de las formas es usar un ServiceLocator apunta a un contenedor específico. Como el localizador generalmente está expuesto como singleton, obtienes tu contenedor de forma gratuita desde cualquier lugar del código.

Por ejemplo, en Unity sería como

// configure the locator somewhere early
UnityServiceLocator locator = new UnityServiceLocator( container );
ServiceLocator.SetLocatorProvider( () => locator );
...
// get the container anywhere
var container = ServiceLocator.Current.GetInstance<IUnityContainer>();

La discusión sobre si el localizador es o no un antipatrón está más allá del alcance. En mi opinión, no es, al menos, más "antipattern" que todo el IoC.