In response to the first comment, I am inclined to agree with the author that autowiring should be avoided. In many cases, you're going to have more than one instance of a given bean type. Consider the simple, and most common case: declarative transaction management. In general, first you create the target object (assume we've defined the _serviceTemplate bean to be a ProxyFactoryBean with a TransactionInterceptor):
<ref local="_myDao" />
<ref local="_myService" />
Once you do this, there is no way to autowire properties of type MyService, just matching on the class. Matching by name, now forces you to follow patterns based on your bean id's. I see this is a bad practice, since bean id's can change, and should only be relevant at the IOC level.
Another example would be datasources. Consider a design where you assume your different services can be distributed. At deployment time, we've decided to provide datasource driven implementations of our DAO layer. The datasource for each dao may be entirely different, necessitating multiple datasource instances (each with a different bean name) to be available. Autowiring is no longer an option if you're using Spring's JdbcDaoSupport (or indirectly HibernateDaoSupport), which has a fixed property name for the datasource.
I find it helpful to explicitly state my injections, as there is never a doubt where anythign is coming from. Tool-wise it makes sense as well, because it's easy to generate a nice dependency graph from an explicitly wired spring config file set. Generating this when autowiring is enabled is not quite so easy.