Is it good practice to inject IUnityContainer into controller class to save extra code

Question

I am using the following in my controller

IAccountRepository AcctRep;
IAccountProductRepository AcctProdRep;

public HomeController(IUnityContainer container)
{
    AcctRep = container.Resolve<IAccountRepository>();
    AcctProdRep = container.Resolve<IAccountProductRepository>();
}

and in my UnityConfig.cs file in the AppStart..

container.RegisterTypes(AllClasses.FromLoadedAssemblies(),
      WithMappings.FromMatchingInterface,
      WithName.Default);

Why?

To Save myself from manually registering about 30 different repositories in UnityConfig.cs like below:

container.RegisterType< IAccountRepository, AccountRepository >();

To Save my Self the Hassle of doing the below in countless controllers

IAccountRepository AcctRep;
IAccountProductRepository AcctProdRep;

public HomeController(IAccountRepository acctRep, IAccountProductRepository acctProdRep)
{
    AcctRep = acctRep;
    AcctProdRep = acctProdRep;
}

and because what i proposed looks neater than above (imagine having to inject 4 Repositories)...

Question is am i having too much of a performance issue, or anything that I am not seeing and can regret in the future?

Edit A little part of this question is similar to the suggested duplicate but not entirely.. I.e. the using of Unity's AllClasses mappings and performance impact of doing the above vs the normal injection and issues I might face in the future if I go down that way.. @Konamiman's approach to the answer is very neat keeping question to see what others have to say..

For the records, the suggested duplicate was [Is it better to create a singleton to access unity container or pass it through the application?](http://stackoverflow.com/questions/2386487/is-it-better-to-create-a-singleton-to-access-unity-container-or-pass-it-through) — Konamiman, Jun 23 '15 at 08:20

Konamiman · Accepted Answer · 2015-06-23T07:10:30.790

I'd say that this is not a good idea because it hurts code maintainability. You are creating a strong coupling of your classes to the dependency injection engine, what if you decide in the future that you want to stop using Unity and (for example) switch to Autofac? It also hurts code readability, because it's not obvious what the class dependencies are.

So the proper way to go is either:

Pass the dependencies in the class constructor. It may seem a hassle at first, but it leads to more readable and maintainable code, and you should always favor code readability over your own write time convencience. Moreover, if you find yourself passing too much parameters in the constructor perhaps it's time to review your design (is your controller doing too much? Perhaps it should depend on a business class instead of directly depending on the four repositories...?)
At the very least, if you still want to pass the dependency resolver to your classes, create an abstraction of the dependency resolver so that you are isolated from the concrete engine used. Something like this should be good enough to start with:

.

interface IDependencyResolver
{
    T Resolve<T>();
}

You can then create and register an implementation of the class for Unity, which will be easily replaceable if ever needed.

what do you think of the UnityConfig.cs part? + from Mark Seemann suggestion I also understand that using Service Locator(.resolve) is an anti pattern.. — inN0Cent, Jun 23 '15 at 08:08
The way you are registering types is fine as long as you have strict one-to-one mapping between interfaces and classes everywhere. As for the Service locator, [avoid it whenever you can](http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern); like I said, pass dependencies in the constructor (preferable) or at least use an abstraction of the dependency resolver. — Konamiman, Jun 23 '15 at 08:18

Is it good practice to inject IUnityContainer into controller class to save extra code

1 Answers1