When is it right to Autowire beans?
Short answer: Never.
Long answer: Never, no, uh-uh, no.
Longer answer: Well OK maybe sometimes.
Automatic wiring is a great time saver for small applications, such as “Hello, World”. Anything more than that and you are heading down a path paved with bad practices and at best it can lead to an inflexible architecture in larger applications.
The various ways of autowiring can be set-up as follows:
// Spring Context XML
<bean id="foo" class="com.springcode.example.Foo"/>
<bean id="useByName" autowire="byName" class="..."/>
<bean id="useByType" autowire="byType" class="..."/>
<bean id="useConstructor" autowire="constructor" class="..."/>
<bean id="useAutodetect" autowire="autodetect" class="..."/>
// Java Class
private Foo foo;
private Foo foo2;
public MyClass() { ... }
public MyClass(Foo foo) { ... }
public setFoo(Foo foo) { ... }
public setFoo2(Foo foo2) { ... }
Use of byName will call the no-args constructor and set a value for foo, but not foo2; use of byType will set values for foo and foo2; use of constructor will call the single arg constructor; and use of autodetect will use the byType autowiring as there is a no-args constructor.
Note that we could have used the @Autowired annotation in MyClass and avoided use of the single arg constructor and the setters.
@Autowired
private Foo foo;
@Autowired
private Foo foo2;
Each method of autowiring leads to its own distinctive issues.
- byName - This sounds like it could be the best option if you want to avoid ambiguity, but you can easily find yourself giving your beans really obtuse “unique” names. This ends up defeating the benefit of Spring doing the work for you.
- byType - This encounters issues in larger applications. By using byType you are forced to only have one bean of each type in your BeanFactory, this then causes issues if you are attempting to have beans with different configurations for the same type.
- constructor - Encounters the same issues as byType.
- autodetect - The functionality behind autodetect is just the same as in byType and in constructor. Thus, you encounter the same issues.
So is there anywhere you can use autowiring, where it wont break things? Well I have been told that in unit testing it is sometimes advisable to use byType autowiring. However, even here you can just use manual wiring.
|
|
|
|
|
|
|
Hi, nice post. I have been wondering about this topic,so thanks for posting. I’ll certainly be coming back to your site. Keep up the good posts
Hi,
I agree with your short and long answer although I strongly belief the longer answer should still be never.
From the horrors I have dealt with especially when a very large codebase is maintained by less experience developers the time saved auto-wiring can be a false economy.Auto-wiring is great for when the task at hand is a (simple) proof of concept where the code with endup in the trash can anyway.
I would say autowiring should never be used unless where there is a proper QA process in place to verify and certify the quality of the code.Although spring configuration via XML can get unwieldy but at least you get the sense that you know what is doing what in the codebase.
“writing code that works is not enough”
I must admit to being quite lucky and have still not come across auto-wiring used commercially. That doesn’t mean I haven’t seen plenty of bad Spring code out there though. Currently back with ATG which is an older IoC framework with no auto-wiring-type functionality for those who don’t know.