aspose file tools*
The moose likes Spring and the fly likes Spring Annotation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Spring Annotation " Watch "Spring Annotation " New topic
Author

Spring Annotation

Muhammed Ismail
Greenhorn

Joined: Jan 30, 2011
Posts: 2
Why we Use @Autowired in Spring Framework?
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

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.
Hauke Ingmar Schmidt
Rancher

Joined: Nov 18, 2008
Posts: 371
To confuse and make code reading and debugging harder.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

I'm not a fan of @Autowire either as I prefer explicit (configuration-based) wiring and @Autowire feels like scattering Global Variables around the application.
Hauke Ingmar Schmidt
Rancher

Joined: Nov 18, 2008
Posts: 371
Global variables that are dynamically created and set by the framework at runtime. Oh joy!
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Hauke Ingmar Schmidt wrote:To confuse and make code reading and debugging harder.


You can't just say something dramatic like that without explaining in detail why you have that opinion.

Mark
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

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.


[My Blog]
All roads lead to JavaRanch
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

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
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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.

Mark
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29255
    
140

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.

Mark

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
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.


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

For instance, Transactions. It is so so so so much easier using the @Transactional annotation, than configuring it in xml with the tx and aop namespaces combined to get the same results.

Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Spring Annotation
 
Similar Threads
Spring Framework Reference / Book
which technology
Which book to learn Spring?
Frameworks
WA #1.....word association