Guidance on usage of IUnityContainer

Topics: Prism v2 - WPF 4, Prism v4 - WPF 4
Oct 5, 2010 at 2:34 AM
Edited Oct 5, 2010 at 2:36 AM


I have recently inherited a reasonably young user interface project with my company (previous person resigned).

Without going into too much detail, one of the project goals is to allow injection of content and views of this content from third parties. To achieve this we are building a service oriented framework that uses dependency injection combined with MVVM techniques and allows people to register their content/views/services during bootstrap and it all magically becomes integrated.

Prism was chosen as primary guidance and in particular the Unity flavor of implementation.

Entering the project at this point I am happy with the technique/technology choices, and do not wish to change them.

The concerns I have at this point is that it appears that (in my opinion) IUnityContainer has been ... abused. It has been injected into just about everything in the framework including base class Views and View Models. It is passed deep into our framework at a confusingly fine granularity -- and this rings alarm bells for me. Individual declarations (local, properties etc) count over 100, and individual uses count over 300, and the project/product is less than one third complete.

From what I can gather, it is being used in the following (primary) ways:

1. Service Locator (confusingly, Container.Resolve is being used in constructors of classes that also use [Dependency] properties)
2. Object factory (Container.Resolve<ConcreteType>() in order to have its dependencies injected)
3. Injection post construction (MyObject obj = new MyObject(myParameter); Container.BuildUp(obj);)
4. Service Context (Container.CreateChildContainer(), register 'local' services/objects in child, and pass around this 'context' to perform 1., 2. and 3.)

My thoughts on these are:

1. I don't so much mind, but for consistency I would prefer to use either service locator or dependency injection (personally preferring DI). I don't like that I do not know the object dependencies by looking at it's constructor or properties, instead I need to read the source code (which for a framework is questionable).

2. Conceptually I don't mind, but I would prefer it to be wrapped in some kind of factory which sits on type of DI instead of using the container as a factory. This is fairly easy to achieve with an open generic type mapping of IFactory<> to UnityFactory<>.

3. Problematic, I would like to use a factory, but would prefer not to create a factory for every single type that might take non-DI injected parameters. This appears to be a common challenge on forums I have read. I could create IMyObjectFactory which has a method Create(myParameter) and then create and instance of UnityMyObjectFactory to allow it to then have DI performed on it, but given the number of types that do this it seems cumbersome and clumsy (as opposed to 2. which is quite clean but only works for types that do not have non-DI dependencies).

4. This one has really got me stumped. I can appreciate the value of context, and sometimes context with has some kind of hierarchy/inheritance/nesting/recursion (whichever you like), but I am struggling to see the value of creating IUnityContainer contexts deep inside your application. On a coarse level, I can see some value in a child unity container that holds services specific to a module, but not to any given service/view/viewmodel or indeed object instance. Whats the benefit? I can override a service at fine granularity, sure, but why? I can't test it. Runtime behavior predictability reduces even more (DI at a course level is enough of a challenge).

My feeling at this point is that IUnityContainer should really only be referenced from the Bootstrapper and most likely and Module that requires integration, but extracting/replacing IUnityContainer with other suitable patterns appears to be quite painful unless I can figure a reasonably generic way to solve 3. and 4.

So this is a call out to some seasoned Prism/Unity veterans.

Are my gut feelings valid?
Which usages sound reasonable and which do not and why?
What recommendations can anyone offer at this point to help me move forward?

A thousand thanks,


Oct 5, 2010 at 4:56 PM

I think you are on the right track.  My team "banned" passing IUnityContainer references into most objects (mostly viewmodels and such).  Of course there were some exceptions but we found that using strict DI felt much clearer, and easier to manage.  It also means it would be easier to replace Unity with something else in the future, if we need to.

Oct 5, 2010 at 5:40 PM

Hi Jahmai,

As most of your concerns are related specifically to Unity and not to Prism scenarios, you could ask this question in the Unity forum, where you might get more accurate guidance.

Fernando Antivero

Oct 5, 2010 at 9:46 PM

Thanks for the feedback John.

Fantivero, my questions are Unity centric, but really they are guidance questions about best practices using such a container within the Prism framework, my apologies if that doesn't translate in my question.

Oct 15, 2010 at 9:27 PM
Edited Oct 15, 2010 at 9:29 PM

Hi Jahmai,

I think this is an interesting question and I didn't take it to be just Unity-centric.  I believe you are asking the more general question of how much dependency your code should have on references to any container, Unity or otherwise, and how best to reduce that dependency.

Overall I agree with johnmathis2001.  That is, use "strict-DI" where-ever you can, so that your code has no references to the container or service-locator.  Any dependencies will be magically supplied by whatever container you happen to be using (which still is a kind of dependency on a general container being available,  but looser).

But what if it is difficult to use "strict-DI" in a particular case?  I don't think it's worth losing too much sleep over the perfectionist goal of having 100%-DI-only.  For example, in Prism's StockTrader sample you will find the following direct reference to the "global" service locator (See: StockTraderRI.Infrastructure\ Behaviors\ RegionPopupBehaviors.cs)

  IRegionManager regionManager = ServiceLocator.Current.GetInstance<IRegionManager>();
I'm sure we could come up with a way to get rid of that dependency, but at what cost?  Probably we would end up with something that was more complex and difficult to understand.  What is the chance that we'll need to reuse this code in a context where a "global" ServiceLocator is not available? If there is almost no chance, then I'd rather put that time into something else.


Oct 18, 2010 at 12:25 AM

Hi SLEverywhere,

Thanks for the considered advice. This is what we have decided to do, which is to reduce dependency on the DI container by using "strict-DI" as much as possible, and then for places that it doesn't make sense or is difficult to achieve, expose a service locator. The trick is exposing the locator in such a way that it doesn't get abused, and educate the team so that misuse is caught in code review.

Thanks :)