Doesn't autowiring limit goal of IoC?

Question

IoC is nice but, used with autowiring (@EJB, @Autowired, @Inject, @SpringBean...), don't you think it limit a goal of IoC?

Actually i don't know so much about autowiring systems in different frameworks but it seems that it's mainly based on types.

When you use @EJB on IService then you need to have only one implementation ServiceImpl to make it work.

What if we want many implementations?

It seems some autowiring annotations can have arguments. For exemple in Stripes you can do: @SpringBean("xxxService") Where xxxService is a spring initialized bean.

In such a case, ok you don't do "new XxxServiceImpl()" But you still put a hardcoded reference to the service implementation you want to use in your bean. It's simply not a class reference but a spring bean reference to the implementation...

What do you think about that? I like autowiring but just wonder myself....

Answer 1

Yes, there are limitations to autowiring (just one implementation of an autowired interface), so it defeats a part of the IoC flexibility when it comes to injecting the proper implementation.

However, I see autowiring as just being a way to reduce configuration. So when 90% of your dependencies can be autowired, you tend to end up with less configuration overall (and the remaining configuration is significant, because it only contains the important (implementation-specific) bits)

Answer 2

I doubt this can be considered an objective question, but let's have a shot at this.

I've had quite some discussions about this, and it's certainly not only you that's thinking this way.

Yes, doing it that way makes IoC somewhat pointless. It still makes it easier because you dont have to figure out the ideal wiring order yourself, but you lose the advantage of being able to switch implementations by changing a configuration file, which is one of the reasons we started with IoC in the first place.

There seem to be two main approaches to switching between implementations now:

1. Use Qualifiers

You can add an annotation on your implementation, and another one on your injection point, which will tell the container which one you want to use. You still have to change your code in two spots though, so it's the same as implementing a sub-interface and wiring that by type. It's also still hard-coded.

1. Use a beanconfigurer

Spring has this beanconfigurer concept, which just replaces the old xml files. You can handle the configuration in a certain class which will tell the container how to wire. I don't see the advantage over the old style (for this cause, xml syntax is more readable), but I guess it's a matter of taste.

For me, the only way to use autowiring by type in a decent way is to play with the classpath, so that you can pop in mocks instead of implementations by including a different class. But since java classpath has such a user-friendly interface, I also don't think this is easier than the old xml way of doing things.

So in the end, I think it all comes down to a matter of taste. Yes, autowiring using annotations is a lot easier, but it does hardcode your configuration into your code, just as you say. The question becomes, does it really change that often that it warrants a 'softcoding' approach?