Is autowiring a hit?

[rasivasu]

I have a feeling that troubleshooting may be difficult with autowiring, if you don't follow all the mapping in your mind. Isn't manual wiring a lot more readable, both for later reading as well as for others?

Also, don't the "@Autowired + @Qualifier" combination increase coupling between beans? And wouldn't we be littering the entire code base with these 'tigher couplings' instead of at a single location, in the case of xml based wiring. I know this givens extra flexibility but would like other's opinion on whether this will ultimately become a pattern or an anti-pattern.

[bytor99999]

I only do @Autowired myself. But that doesn't mean that what you say doesn't have truth to it, at different levels.

First about autowiring xml or annotations, yes there is a lot less documentation of what gets wired where that requires you to know about your architecture and more details. But as a developer, I would say you should know that anyway, regardless of which configuration approaches you take. But for new developers, they probably would take more time to figure things out.

About the annotation, and bean naming and qualifiers. Yes, you get a bit more details of connection when you rely on naming and qualifying coupled in your code. So it becomes less refactor friendly. However, there are solutions, ways to make that not be a problem, or need to occur. One way, is most of your classes will only have one implementation in your classpath at runtime, therefore never have to qualify it because Spring will automatically inject that one implementation. So for swapping out say Jdbc Repository versions of my repository interfaces with Hibernate versions, I just include the Hibernate Repository jar files with just the Hibernate implementation in my classpath at runtime. To switch back, remove the hibernate implementation jar with the jdbc implementation jar. No code change, no annotation config changes at all

About Annotations in general and coupling in code. 1) You only need to have the definition of the annotation at compile time. It is not required to be there at runtime. It would always be a separate class that might act on the annotation. But if neither are there in your classpath at runtime, the annotations are completely ignored as if they weren't there.

All approaches have pros and cons and all the pros and cons are 100% valid. And each have trade offs. For me the trade off of annotations is that my configuration isn't at a single location like you mentioned. But my pro, is I develop a lot faster. I am typically working on a use case, so I can go to one place, the Service layer class and automatically see my configuration because of the Annotations in the class, otherwise I would have to go to two places, the Service layer class and the xml if I wasn't using annotations.

My recommendation in the end always goes to consistency. Whatever approach you choose, make sure you consistently use it, and that it is a team decision and that everyone in the team is consistently using the same approach that the team decided on.

Hope that helps

Mark

[bytor99999]

Oh and the sticky on this forum has a poll about annotations.

http://forum.springsource.org/showth...n-do-you-favor

So, in terms of is it being used, or a "hit"? yes definitely is being used and wanted.

Mark

[rasivasu]

Thank you Mark. It is good to know that there are trade-offs and people are still finding sufficient benefits in using annotations.