CODEWITHSUNDEEP
inversion-of-control
Sylvain
Sylvain

Reputation: 19249

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:

Upvotes: 4

Views: 575

Answers (4)

Rich Remer
Rich Remer

Reputation: 2603

The IoC container.

No, seriously; start writing everything without an IoC container. Once you've gotten the hang of how IoC works and started using it in your code, you'll start to see the areas where the container will help. That is when you should add the container: when you are ready to solve a real issue with the container. Don't use a container just because someone said containers are a Good Idea™.

Upvotes: 0

Nicholas Blumhardt
Nicholas Blumhardt

Reputation: 31757

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

Upvotes: 3

amazedsaint
amazedsaint

Reputation: 7642

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.

Upvotes: 2

NotDan
NotDan

Reputation: 32213

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.

Upvotes: 1

Related Questions