Is it better to create a singleton to access unity container or pass it through the application? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

开发者_JS百科

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I am dipping my toe into using a IoC framework and I have choosen to use Unity. One of the things that I still don't fully understand is how to resolve objects deeper into the application. I suspect I just haven't had the light bulb on moment that will make it clear.

So I am trying do something like the following in psuedo'ish code

void Workflow(IUnityContatiner contatiner, XPathNavigator someXml)
{
   testSuiteParser = container.Resolve<ITestSuiteParser>
   TestSuite testSuite = testSuiteParser.Parse(SomeXml) 
   // Do some mind blowing stuff here
}

So the testSuiteParser.Parse does the following

TestSuite Parse(XPathNavigator someXml)
{
    TestStuite testSuite = ??? // I want to get this from my Unity Container
    List<XPathNavigator> aListOfNodes = DoSomeThingToGetNodes(someXml)

    foreach (XPathNavigator blah in aListOfNodes)
    {
        //EDIT I want to get this from my Unity Container
        TestCase testCase = new TestCase() 
        testSuite.TestCase.Add(testCase);
    } 
}

I can see three options:

1. Create a Singleton to store my unity container that I can access anywhere. I really am not a fan of this approach. Adding a dependency like that to use a dependency injection framework seems a little on the odd side.
2. Pass the IUnityContainer to my TestSuiteParser class and every child of it (assume it is n levels deep or in reality about 3 levels deep). Passing IUnityContainer around everywhere just looks odd. I may just need to get over this.
3. Have the light bulb moment on the right way to use Unity. Hoping someone can help flick the switch.

[EDIT] One of things that I wasn't clear on is that I want to create a new instance of test case for each iteration of the foreach statement. The example above needs to parse a test suite configuration and populate a collection of test case objects

---

The correct approach to DI is to use Constructor Injection or another DI pattern (but Constructor Injection is the most common) to inject the dependencies into the consumer, irrespective of DI Container.

In your example, it looks like you require the dependencies TestSuite and TestCase, so your TestSuiteParser class should statically announce that it requires these dependencies by asking for them through its (only) constructor:

public class TestSuiteParser
{
    private readonly TestSuite testSuite;
    private readonly TestCase testCase;

    public TestSuiteParser(TestSuite testSuite, TestCase testCase)
    {
        if(testSuite == null)
        {
            throw new ArgumentNullException(testSuite);
        }
        if(testCase == null)
        {
            throw new ArgumentNullException(testCase);
        }

        this.testSuite = testSuite;
        this.testCase = testCase;
    }

    // ...
}

Notice how the combination of the readonly keyword and the Guard Clause protects the class' invariants, ensuring that the dependencies will be available to any successfully created instance of TestSuiteParser.

You can now implement the Parse method like this:

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

    foreach (XPathNavigator blah in aListOfNodes) 
    { 
        this.testSuite.TestCase.Add(this.testCase); 
    }  
} 

(however, I suspect that there may be more than one TestCase involved, in which case you may want to inject an Abstract Factory instead of a single TestCase.)

From your Composition Root, you can configure Unity (or any other container):

container.RegisterType<TestSuite, ConcreteTestSuite>();
container.RegisterType<TestCase, ConcreteTestCase>();
container.RegisterType<TestSuiteParser>();

var parser = container.Resolve<TestSuiteParser>();

When the container resolves TestSuiteParser, it understands the Constructor Injection pattern, so it Auto-Wires the instance with all its required dependencies.

Creating a Singleton container or passing the container around are just two variations of the Service Locator anti-pattern, so I wouldn't recommend that.

---

I am new to Dependency Injection and I also had this question. I was struggling to get my mind around DI, mainly because I was focusing on applying DI to just the one class that I was working on and once I had added the dependencies to the constructor, I immediately tried to find some way to get the unity container to the places where this class needed to be instantiated so that I could call the Resolve method on the class. As a result I was thinking along the lines of making the unity container globally available as a static or wrapping it in a singleton class.

I read the answers here and did not really understand what was being explained. What finally helped me "get it" was this article:

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

And this paragraph in particular was the "light bulb" moment:

"99% of your code base should have no knowledge of your IoC container. It is only the root class or bootstrapper that uses the container and even then, a single resolve call is all that is typically necessary to build your dependency graph and start the application or request."

This article helped me understand that I actually must not access the unity container all over the application, but only at the root of the application. So I must apply the DI principle repeatedly all the way back to the root class of the application.

Hope this helps others who are as confused as I was! :)

---

You should not really need to use your container directly in very many places of your application. You should take all your dependencies in the constructor and not reach them from your methods. You example could be something like this:

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);
        } 
    }
}

And then you do it the same way all over the application. You will, of course, at some point have to resolve something. In asp.net mvc for example this place is in the controller factory. That is the factory that creates the controller. In this factory you will use your container to resolve the parameters for your controller. But this is only one place in the whole application (probably some more places when you do more advanced stuff).

There is also a nice project called CommonServiceLocator. This is a project that has a shared interface for all the popular ioc containers so that you don't have a dependency on a specific container.

---

If only one could have a "ServiceLocator" that gets passed around service constructors, but somehow manages to "Declare" the intended dependencies of the class it is being injected into (i.e not hide the dependencies)...that way, all(?) objections to the service locator pattern can be put to rest.

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

Sadly, the above obviously will only ever exist in my dreams, as c# forbids variable generic parameters (still), so manually adding a new generic Interface each time one needs an additional generic parameter, would be unwieldy.

If on the other hand, the above could be achieved despite the limitation of c# in the following way...

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

This way, one only needs to do extra typing to achieve the same thing. What i am not sure of yet is if, given the proper design of the TArg class (i assume clever inheritance will be employed to allow for infinite nesting of TArg Generic parameters), DI containers will be able to resolve the IServiceResolver properly. The idea, ultimately, is to simply pass around the very same implementation of the IServiceResolver no matter the generic declaration found in the constructor of class being injected into.