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