This week's giveaway is in the JDBC forum.
We're giving away four copies of Java Database Connections & Transactions (e-book only) and have Marco Behler on-line!
See this thread for details.
Win a copy of Java Database Connections & Transactions (e-book only) this week in the JDBC forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

About Spring annotation @Autowired & @Qualifier, does this run in the opposite direction of IoC?  RSS feed

Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, everyone, I'm a newbie to Spring.
I have confused by the @Autowired for days, my question is that, the designer use "@Autowired + @Qualifier" to streamline XML configuration, but on the other hand, it seems like we return back to the way where there are lots of dependency between classes.

So, is it a bad idea to use @Qualifier in spring projects?

author & internet detective
Posts: 39286
Eclipse IDE Java VI Editor
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's still inversion of control when you use annotations. They key is that Spring is still constructing the objects for you. Just like when you specified this information in XML. I don't see why there would be more dependencies when specifying the autowiring via annotations vs XML.

Or maybe you are asking about autowiring in general (vs annotations.) If the Java classes use interfaces and you are injecting concrete classes, you have less dependencies than if you were to hard coded the concrete class all over. Using qualifiers lessens this somewhat. I find that most of the time, I don't need to use a qualifier though.
Sheldon June
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Jeanne,

Thanks for your reply, it seems like I misunderstand the concept of DI, after reading your post, I went to find the explanations of DI and IoC from wiki and think about it again, then understood what was wrong in my mind.

Posts: 2759
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
DI and IoC are both meant to remove dependency between classes and the initialization logic of other classes. It's not meant to remove depdnencies between those classes.


So, let's say you have a class called Refrigerator. And you have another Class called CokeBottle. Let's say the Refrigerator has one method called CokeBottle giveCoke() throws NoMoreCokeForYouException. Without any notion of a Factory method, the Refrigerator will have to create CokeBottles. Of course, that's not how real world works, Refrigerators are not factories. They "merely" hold coke bottles, not literally give birth to them. If you have another class called Cooler, you wouldn;t want to replicate the code to create a CokeBottle in the Cooler class

So, you can introduce a Factory class called CokeBottleFactory. Your Refrigerator and Cooler can both call the CokeBottleFactory to get a CokeBottle whenever it needs one. Now, you can share code, but both Refrigerator and Cooler are dependent on CokeBottleFactory. It's better than before, but it's not good

This is where DI comes in. Your DI framework is more or less like a GroceryStoreClerk. His job is to fill the Refrigerator with CokeBottle. He makes sure he talks to the factory, get enough bottles, and "inject" them into the Refrigerator. Now the Refrigerator can function as a pure holder of CokeBottle. It has no dependency on the CokeBottleFactory. In fact, you can take the same Refrigerator and stick it in a restaurant, and the RestaurantWorker can be the DI framework in charge of filling the Refrigerator. The Refrigerator doesn't care one bit


Practically, in most MVC applications, you have the View dependent on the Controller, and the Controller Dependent on the DAO. This is how as it should be. However, without DI, you have the Controller dependent on the initialization logic of DAO. The Controller needs to know which database to connect to, which username/password (or needs to know a factory class that knows these things) to get the DAO. So, the Controller is dependent on 2 things:- a) DAO and b) the DAOFactory. Similarily, the View is dependent on 2 things a) Controller and b) ControllerFactory.

DI allows you to eliminate the dependencies between classes and other factories by flipping the whole thing on it's head. The DI framework does all the Factory business, and injects dependencies as and when required.
The government thinks you are too stupid to make your own lightbulb choices. But this tiny ad thinks you are smart:
how do I do my own kindle-like thing - without amazon
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!