This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
If a bean wants to access another bean, typically it needs to configured in the Spring properties. This is referred to as wiring them together.
@Autowire allows a bean to access another without configuration.
I completely disagree. I dislike xml. When you have a large application you have to hunt and peck around just searching and trying to find your bean you are looking for. There is a lot more typing to do, and you don't get no type safety in the strings "" in xml. When you are working on a use case, you have to go through two files, your Java class file and the xml switching back and forth. I find it wastes a lot of time for me.
With @Autowired and @Component, I find it a lot easier to work on my code, see what is going on, all with just looking at one java file, which happens to be the use case I am working on and I see it all. How many times are you working on the entire application and have to see everything? I find that over 90% of my time in development I am working on just one use case and seeing the dependencies in that one java class I am working on makes more sense to me. Even if I tried to work on more than one use case, well that is too much to try to keep in your head at one time. Also with annotations you get type saftey, your definition of the annotation only has to be in your classpath at compile time. It never has to be there at runtime.
To the Original Poster.
@Component replaces <bean> tags in xml and
@Autowired replaces <constructor-arg> and <property> tags in xml. You can also put @Autowired on an instance variable.
Christophe Verré wrote:I'm also a heavy user of the @Autowired and @Component annotations. I find it easier to use these annotations rather than declaring beans in the context file.
I use them too, but they still make me uncomfortable.
I still like explicit wiring. In that case you can manage the application layers and the visibility and accessibility of beans.
Now that (to a certain extent) any bean can reach out and grab any other bean we lose this. We didn't have the problem because we were careful to avoid it, but in our case we had Spring MVC, a Spring based service layer and a Spring based DAO layer. If the junior devs had @Autowired from the front to the back it would have been a bad practice in general and caused issues that may not have been picked up early.
It is also possible that they could add the wiring to the XML config, but in my opinion it is easier to watch for changes in essential config files and less easy for all classes.
Mark Spritzler wrote:And there isn't any restriction on the combination of all configuration styles. You can use JavaConfig, xml, and Annotations in your application at the same time, or any combination therein.
So for me, all my Services, Repositories, Controllers etc are annotated, but my infrastructure beans like TransactionManager, DataSource, SessionFactory are all in xml.
That makes sense to me. Things like the DataSource aren't code based constructs and are more likely to change independently of the code too.
Awhile back, I wasn't a big fan of autowiring. My reasons were many of the same reasons stated here (hard to debug, difficult to deal with missing/multiple matching dependencies, etc, etc). I even stated those reasons...but I couldn't honestly say that I had experienced those problem...just that I imagined that they would exist.
Then Spring 2.5 came along and brought me component scanning. Autowiring and component-scanning go hand-in-hand. And I liked component-scanning...even though it meant that I was also doing more autowiring. Eventually, it occurred to me that the benefits of component-scanning and autowiring (less XML, less duplication between my XML and the Java code it was configuring, automatic discovery of beans, etc) were *FAR* greater than my perceived problems. In fact, I rarely actually encounter any of those problems that I attributed to autowiring. And when I do, it's usually not that big of a deal to sort it out.
As someone pointed out, Spring doesn't force you either way. If you like XML, then by all means...write XML config. If you like component scanning and autowiring, then take advantage of it. Maybe you like component-scanning in some places (it's wonderful when working with Spring MVC), but would prefer to explicitly wire stuff in other places. And you can still do explicit configuration with *no XML* by using Spring's Java configuration option.