Search code examples
inversion-of-control

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

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.
Solution

  • 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.