What are the things to avoid when using a IoC container?

Question

I'm introducing an IoC Container in an architecture for the first time. I'm looking for things that one should not do with an IoC Container. I want to avoid the pitfalls of using an IoC container. I don't want to misuse or overuse it.

Can you help me put up a list of things to avoid when using a IoC container?

I have on item on my list so far:

• Don't let every class access the container (don't make it a public Singleton). Only a few top level classes should access the container.

Answer 1

I'd say don't use config files for registering types unless you absolutely have to. It makes refactoring hard and it's also harder to unit test with your default (non mock) mappings.

Answer 2

If you are putting an IoC in place, I suggest you to have a look at http://docs.codehaus.org/display/YAN/IoC+Container

Here are few interesting points

• The most obvious one, container should not require business objects assembled by it to implement any interface, to inherit any class, to call any API. This avoids direct dependency on the container.

• The container should not require business objects to conform to any coding convention, such as "you have to expose public constructor", "you have to expose Java Bean setters", "you have to have a method named like injectXXX", "you have to use a special annotation" etc. Such restriction places an implicit dependency on the container because the programmers of the business objects still have to be aware of the do's and dont's from the container.

• Do not depend on any IoC container API in your IoC objects. It is a tragedy to violate the principle of IoC by using an IoC container.

• IoC container is for the code that assembly objects together; it is for the configuration of the system. After all, it is not for the business objects.
• Declarative API is preferable. It is nice to expose a declarative API rather than one that requires procedural coding.

Answer 3

Maybe this is more simplistic than the kind of advice you're looking for, but my suggestion would be: don't get hung up on the container.

IoC is 1% about the container, and 99% about the components inside. They're what gives the application value - the container on the other hand is infrastructural junk ;)

You should be able to design those components in the most effective way for your application.

If you start out with what seems to be a good container, and have no trouble creating well-encapsulated, clean, natural components that don't depend heavily on the container API, then you're on the right track.

If, however, you find yourself jumping through hoops to fit your design into the container, and you don't think the problem is with your design, the immediately find a container without the limitation that's impacting you, and just keep moving forwards.

Hope this helps!

Nick