¿Es mejor crear un singleton para acceder al contenedor de unity o pasarlo a través de la aplicación?

Soy nuevo en Dependency Injection y también tenía esta pregunta. Yo estaba luchando para conseguir mi mente alrededor de DI, principalmente porque me estaba centrando en aplicar DI solo a la clase en la que estaba trabajando y una vez que había añadido las dependencias al constructor, inmediatamente traté de encontrar alguna manera de conseguir el contenedor de unity a los lugares donde esta clase necesitaba ser instanciada para que pudiera llamar al método Resolve en la clase. Como resultado, estaba pensando en hacer el contenedor unity disponible globalmente como estático o envolviéndolo en una clase singleton.

Leí las respuestas aquí y realmente no entendí lo que se estaba explicando. Lo que finalmente me ayudó a" conseguirlo " fue este artículo:

Http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container

Y este párrafo en particular fue el momento de la "bombilla":

"99% de su base de código no debe tener conocimiento de su contenedor IoC. Es solo la clase raíz o bootstrapper que usa el contenedor e incluso entonces, una sola llamada de resolución es todo lo que normalmente es necesario para construir su gráfico de dependencias e iniciar la aplicación o solicitud."

Este artículo me ayudó a entender que en realidad no debo acceder al contenedor de unity en toda la aplicación, sino solo en la raíz de la aplicación. Así que debo aplicar el principio DI repetidamente hasta la clase raíz de la aplicación.

Espero que esto ayude ¡otros que están tan confundidos como yo! :)

Realmente no debería necesitar usar su contenedor directamente en muchos lugares de su aplicación. Debes tomar todas tus dependencias en el constructor y no alcanzarlas desde tus métodos. Que ejemplo podría ser algo como esto:

public class TestSuiteParser : ITestSuiteParser {
    private TestSuite testSuite;

    public TestSuitParser(TestSuit testSuite) {
        this.testSuite = testSuite;
    }

    TestSuite Parse(XPathNavigator someXml)
    {
        List<XPathNavigator> aListOfNodes = DoSomeThingToGetNodes(someXml)

        foreach (XPathNavigator blah in aListOfNodes)
        {
            //I don't understand what you are trying to do here?
            TestCase testCase = ??? // I want to get this from my Unity Container
            testSuite.TestCase.Add(testCase);
        } 
    }
}

Y luego lo haces de la misma manera en toda la aplicación. Usted, por supuesto, en algún momento tendrá que resolver algo. En asp.net mvc por ejemplo, este lugar está en la fábrica del controlador. Esa es la fábrica que crea el controlador. En esta fábrica utilizarás tu contenedor para resolver los parámetros de tu controlador. Pero esto es solo un lugar en toda la aplicación (probablemente algunos lugares más cuando haces cosas más avanzadas).

También hay un buen proyecto llamado CommonServiceLocator. Este es un proyecto que tiene una interfaz compartida para todos los contenedores ioc populares para que no tenga una dependencia de un contenedor específico.

Si solo uno pudiera tener un "ServiceLocator" que se pasa alrededor de los constructores de servicios, pero de alguna manera se las arregla para "Declarar" las dependencias previstas de la clase en la que se está inyectando (es decir, no ocultar las dependencias)...de esa manera, todos(?) las objeciones al patrón de localización de servicios pueden ser dejadas de lado.

public class MyBusinessClass
{
    public MyBusinessClass(IServiceResolver<Dependency1, Dependency2, Dependency3> locator)
    {
        //keep the resolver for later use
    }
}

Lamentablemente, lo anterior obviamente solo existirá en mis sueños, ya que c# prohíbe los parámetros genéricos variables (todavía), por lo que agregar manualmente una nueva interfaz genérica cada vez que se necesita un parámetro genérico adicional, sería difícil de manejar.

Si por otro lado, lo anterior podría lograrse a pesar de la limitación de c# de la siguiente manera...

public class MyBusinessClass
{
    public MyBusinessClass(IServiceResolver<TArg<Dependency1, TArg<Dependency2, TArg<Dependency3>>> locator)
    {
        //keep the resolver for later use
    }
}

De esta manera, solo se necesita escribir extra para lograr lo mismo. De lo que todavía no estoy seguro es si, dado el diseño adecuado de la clase TArg (supongo que se empleará una herencia inteligente para permitir el anidamiento infinito de los parámetros genéricos TArg), los contenedores DI podrán resolver el IServiceResolver correctamente. La idea, en última instancia, es simplemente pasar la misma implementación de IServiceResolver sin importar la declaración genérica encontrada en el constructor de la clase que se inyecta.