3

I have an IoC container (If you want a specific one to look at, it's very similar to Unity) and I'm working on how I want to integrate it into my application. My overall goal for this exercise is to transform this horrendous code I wrote into something much more testable.

I can create the IoC container and register types and I understand the fundamentals of how it is supposed to accomplish it's goal. My question is should I be injecting the container down into objects that need it, or should the objects that need it look it up using a Service Locator pattern? Realistically I see myself having to reference the container in two or three layers of my application.

Improve this question
0

1 Answer 1

Reset to default
2

Rather than injecting the container in your object and have your objects use the injected container, you should have the container inject the parameters (dependencies) in the constructor of your objects.

This approach makes it very easy to test your code as you can have the container take care of dependencies in the code but in your test you can instantiate the object themselves and inject them with mock or fake objects if need be.

Also, this way you don't have to resolve all the dependencies manually in your code and you can let the container take care of this job.

Implementation of this technique depends on which container you are using but normally it can inject constructor arguments.

In MEF (Microsoft Extensibilty Framework) for example you can use the [ImportingConstructor] attribute. It's also doable in Windsor (from the Castle project), Unity and other containers.

EDIT: If for some reason you can't pass parameters to the constructor, this approach can't be used. In that case I would use the Service Locator pattern and have a static Service Locator that is used in the application.

Improve this answer
3
  • I'd been so focused on trying to use empty constructors I hadn't even considered this, and thinking about it now that really is an elegant solution. I was going to use this to inject objects needed by the view into the view. I am writing this in Visual Basic so empty constructors on view objects are really needed. Realistically, since theres no logic in them I suppose I could bypass DI for the view layer and have it instantiate the objects it needs directly. I won't be unit testing it anyway. Should I reconsider any of those conclusions?
    – Andrew
    Commented Apr 7, 2011 at 17:39
  • In most situation I would personnaly use the container to inject dependencies like I mentionned in my anwser. In cases where I can't pass parameters to the constructor, I normally use the Service Locator pattern with a service locator that is defined with a static class. Personnally I would reconsider not using any tests in the project.
    – Gilles
    Commented Apr 7, 2011 at 17:46
  • I'll be unit testing, but I don't have any plans to unit test my view layer. It has no logic in it, and displays the values only through data bindings. I'll think about it though and use a Service Locator there if need be. Thank you so much!
    – Andrew
    Commented Apr 7, 2011 at 17:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.