Good or bad Unity design: Injecting the complete container or only explicit Interfaces?

Question

This is a bad or good design question.

I find it extreme convenient to always inject the complete Unity container in my modules.

1.) You never know, what resources you will need. 2.) The class constructor never needs to be changed, if you need more resources of the container.

This looks like this:

public class ServiceLocator: IServiceLocator
{
    private IUnityContainer _container = null;

    public ServiceLocator(IUnityContainer container)
    {
        _container = container;
    }


    public void DoSomething()
    {
       var x = this._container.Resolve<IXInterface>();
       var y = this._container.Resolve<IYInterface>();      
       x.Do();
       y.Do();
   }
}

In tutorials and unity examples, I often see, that you only should inject the resources, that you really need. That looks like this:

public class ServiceLocator: IServiceLocator
{
    private XInterface _x = null;
    private YInterface _y = null;

        public ServiceLocator(Ixnterface x,  IYnterface y)
        {
            _x = x;
            _y = y;
        }


         public void DoSomething()
        {
            _x.Do();
            _y.Do();    
        }
}

My questions are:

What do you think is better design?

Why would you only inject explicit Interfaces, when the Unity container has all resources in it?

What are the problems in the future?

The only problem I see for the future is, that you ALWAYS have to have a Unity container in the future and if you don't have it, you have to rewrite the module.

What do you think?

EDIT: Some of the best answers I have found is, that the first version is not dependency injection, it is some kind of "Service Locator Pattern", which can cause many problems.

It can be found here:

http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/

Off topic I believe. but the container should only be used in the [Composition Root](http://blog.ploeh.dk/2011/07/28/CompositionRoot/) and not injected into every component. — Sam Holder, Sep 23 '15 at 14:40
Everyone who's ever passed the container, or created a Singleton for it, has regretted it. I'm listening to the [.NET Fringe keynote](https://www.youtube.com/watch?v=MP8pIXHm31E) right now, where Jimmy Boggard explains how he regretted creating a static `Mapper` and the pain he went through to remove it — Panagiotis Kanavos, Sep 23 '15 at 14:43
Please comment this question, even if it is a duplicate. Maybe there are things that haven't been said before anywhere else. Thank you. — Michael, Sep 23 '15 at 14:48

score 1 · Accepted Answer · answered Sep 23 '15 at 14:40

1

In the first approach, you've got a dependency on the interfaces you need, plus you're adding another one to the container:

var x = this._container.Resolve<IXInterface>();
var y = this._container.Resolve<IYInterface>();

So you've gone against one of the main reasons for DI in the first place.

answered Sep 23 '15 at 14:40

James Thorpe

31,411
5
72
93

What I understood from your answer is: The first solution adds 3 dependencies to the module and 2 dependencies to the container. The second solution adds 2 dependencies to the module and 2 dependencies to the container. So the first solution is one dependency too much. – Michael Sep 23 '15 at 15:32
@Michael The second solution doesn't have _any_ dependencies on the container. At some level you will have a configuration telling the container about your `ServiceLocator`, but the `ServiceLocator` itself only has dependencies on `IXInterface` and `IYInterface` and doesn't know about the container _at all_. – James Thorpe Sep 23 '15 at 15:34
Thank you James. I will have two or three days of intensive refactoring, as I don't want a bad or even rediculous code design. Yesterday I came to an own answer to this question: If you do DI without any "container framework", you would NEVER add any unnecessary dependency on a module, that you don't need. Second: An important ascpect of using components is to make them reusable in other/new software projects, so you won't have to write them again. You can not be sure, to have any container framework in another software project, but you can easily put independent components together. – Michael Sep 24 '15 at 01:14
This following blog post is also very good, because it says, that you are hiding the dependencies from the class consumer, if you use some kind of service locator. If I inject only the container, no one ever knows, which dependencies the class really needs. Who can ever know, which classes need to registered to the container? http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/ – Michael Sep 24 '15 at 01:42

Good or bad Unity design: Injecting the complete container or only explicit Interfaces?

1 Answers1