UnityContainer usage and best practices

Question

Hello,

Is it wrong to use UnityContainer in an app to access references to objects from different parts of the application (but the same assembly)?

The application (WPF) has several regions that need to access each other and I have used UnityContainer to do that. For example, the "main" region (which is a drawing area) has a presenter behind it, that manages all it's business logic, and I have registered this instance of presenter in the container, and in other parts of the application where i need to access it i to control that region, i access it via UnityContainer.

Not sure if that's a good practice or a bad one.

Answer 1

No, in fact, that's kind of what its purpose it. There is a library out there called ServiceLocator that works good that allows you to switch out IoC containers, provides a way to lookup the container, etc. I find it overkill in that I've never had to swap out containers... Using a static "factory" to get the container is usually good enough. Usually, only the top level class has to call it and it is responsible for assembling all the dependencies.