Estoy escribiendo una nueva biblioteca .NET para uso interno en mi empresa que utilizará IoC mediante Dependency Injection. Naturalmente, esta biblioteca será mucho más fácil de usar si usamos un contenedor IoC para resolver instancias.Introducción de un contenedor IoC a código heredado
Sin embargo, el código que realizará las llamadas a esta biblioteca NO utiliza actualmente Inyección de dependencia de ningún tipo, y la refacturación del código heredado para usar DI está fuera del alcance de mi proyecto. Entonces, ¿cuál es la mejor manera de comenzar a usar un contenedor en este código heredado para obtener instancias de mi nueva biblioteca?
De ser posible, me gustaría no tirar basura en dicho código heredado con referencias difíciles a cualquier contenedor de IoC que elija. Como soy relativamente nuevo en DI, es bastante probable que cambiemos de opinión sobre qué contenedor queremos usar en algún momento.
Si envuelvo mi contenedor en algo como la biblioteca CommonServiceLocator en CodePlex, ¿sería razonable?
¿Qué han hecho otras personas?
http://davybrion.com/blog/2009/11/integrating-your-ioc-container-with-agatha/ –
Gracias. Parece una respuesta muy similar a la primera. Eso es exactamente lo que terminé haciendo, por cierto. Creé mi propia clase Container que simplemente envuelve a Windsor, y dejo que mis desarrolladores la usen como Localizador de Servicios. Cuando sea factible, por supuesto, intento que usen el contenedor solo en la parte de arranque de la aplicación para evitar asumir una dependencia de contenedor en todas partes, pero no siempre funciona de esa manera. Esta es una situación de código heredado, después de todo. –