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

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.