Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Spring Annotation

 
Muhammed Ismail
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why we Use @Autowired in Spring Framework?
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To confuse and make code reading and debugging harder.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Global variables that are dynamically created and set by the framework at runtime. Oh joy!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author & internet detective
Marshal
Posts: 34422
347
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Craig Walls
author
Ranch Hand
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic