Spring所谓的自动装配，实质就是实现了对依赖注入的一个简化操作，而依赖注入就是Spring帮助你完成对象的组织关系的一种手段。随着Spring的不断发展，我已经无法搞清楚自动装配的本质和原理了。所以，下面就来梳理一下。
首先，要记住一个关键词：依赖注入。所有的手段都是为此服务的，而所有的发展都是为了更加简便，“智能”的实现这个目的。
1. xml手动配置<property>标签时代
这是Spring实现依赖注入最初的依赖注入的手段。很直观，如果要注入一个属性，需要配置一个属性名称，一个引用的名称。Spring去傻傻的根据配置完成依赖注入即可。
<bean id="cat" class="com.keqing.autowired.Cat"></bean>
<bean id="dog" class="com.keqing.autowired.Dog"></bean>
<bean id="p1" class="com.keqing.autowired.People">
<property name="cat" ref="cat"/>
</bean>
2. xml手动配置autowire标签属性时代
我们省略配置<property>标签这一步，通过配置标签属性autowire="byName",也可以完成上述的工作。这里隐含了一些约定俗成的规矩。第一，属性名称和setter方法的方法名一致；第二，引用类型的名称和setter方法的方法名一致。这个时代其实更像一个过渡的时代，用处不大，但是，为后面更智能的发展做好了铺垫。也更能够体现“约定大于配置”这个思想。
<bean id="cat" class="com.keqing.autowired.Cat"></bean>
<bean id="dog" class="com.keqing.autowired.Dog"></bean>
<bean id="people" class="com.keqing.autowired.People" autowire="byName"></bean>
3. xml配置全局自动装配时代
我们还可以省略单个的bean标签中配置标签属性autowired，通过配置统一的自动装配策略来实现我们进一步偷懒的想法。其实，我是写到这里才想到这个方式的，其实，路都是一步步走出来的，明白了过去的路径发展，就能推导出未来的发展方向。我还是有一点印象，就是有过这个配置。并且，也有Mybatis全局xml配置对我的影响。我就想Spring中应该也有类似的配置。我专门去查了一下，果然还有。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
https://www.springframework.org/schema/context/spring-context.xsd"
default-autowire="byName">
<bean id="cat" class="com.keqing.autowired.Cat"></bean>
<bean id="dog" class="com.keqing.autowired.Dog"></bean>
<bean id="people" class="com.keqing.autowired.People"></bean>
</beans>
以上代码关键的地方在于default-autowire="byName"。有了这个配置，我们就不用在每一个bean标签中使用autowire标签属性来配置自动装配实现依赖注入了。但是，这个其实也是个过渡阶段，为我们的下一个阶段做准备。还是要提醒一句，实现简便和只能的前提是“约定大于配置”，就是这个思想才能推动简便和智能的。
4. xml配置注解驱动，类中配置注解特性时代
xml配置发展到这个地步，已经没有什么可玩的余地了。必须寻找新的手段来拓展发展边界，这是Spring发展的关键一步。其实，前面我们看到了很多约定俗称的重复代码，我们通过约定大于配置的手段，进一步简化了配置。而我们xml中剩余的配置都是关于对象创建的。关于自动装配，我们就没有进一步发展的空间了吗？我想应该是的。我们必须要提出一套完整的新方案来取代xml配置，来提高简便性。那就是注解。这个阶段显然是这套方案的一部分，也是一个过渡阶段。
<context:annotation-config></context:annotation-config>
<bean id="cat" class="com.keqing.autowired.Cat"></bean>
<bean id="dog1" class="com.keqing.autowired.Dog"></bean>
<bean id="people" class="com.keqing.autowired.People"></bean>
上面的xml中开启注解驱动
public class People {
@Autowired
private Dog dog;
@Autowired
private Cat cat;
}
上面的java类中利用注解自动装配，实现了依赖注入。
5. 精简xml配置，省略bean标签配置
其实，自动装配发展到上面这一步，就已经完结了。但是呢，注解这是一整套方案，我呢，就把这一整套方案都捋一下，免得糊里糊涂，从这个阶段，到最后，其实都是整个Spring的发展方向。其实，从开始使用注解，就已经是星星之火了，可以燎原这也是大势所趋。刚开始学习的时候，人们还说，注解不便于管理，带来了复杂性，但是，现实都是打脸的。注解的使用当然是有弊端的，就是没有xml那样把一些固定的配置来集中管理，这一部分有点，java以后是否能够取代就不得而知了。使用注解的好处也是能够看出来的，不需要解析xml了，xml毕竟不是java体系本身的东西。如果利用反射去解析注解，那么都是自家技术应该更好，更方便的解析。注解也进一步减少了xml中的配置，当然在类中的注解配置可没有减少，但是，这就为Spring Boot的发展奠定了基础。
<context:annotation-config></context:annotation-config>
<context:component-scan base-package="com.keqing"></context:component-scan>
@Component
public class People {
@Autowired
private Dog dog;
@Autowired
private Cat cat;
}
@Component
public class Dog {
}
@Component
public class Cat {
}
上面，我们可以看到xml中的配置进一步压缩了，但是注解也在迅速膨胀中。
6. 省略xml配置
既然都走到这一步了，我们把配置都搬到了注解上，能不能彻底把xml干掉呢。我没有过这个想法，所以，我就不会发明Spring Boot。很多人也没有这个想法，所以SSM,SSH框架才能大行其道这么些年。其实，发展到第三步的时候，xml的气数已尽。后面和注解配置使用，都是一个过渡的阶段。要说注解真有什么好处，就是配置相对能够简单，配置信息总要去xml中去看，也是一件挺烦人的事情。而且配置信息就写在类中的脑门上也是比较清晰了。但是，我总感觉，注解这个玩意来配置一些固定套路的东西，实在是没有什么优势可言，是配置变得更加零散了。不利于我们去寻找维护。后续的Spring Boot就非要依靠全注解这个特性吗？肯定不是，xml也能够实现。Spring Boot更多的是对“约定大于配置”这个思想的良好实现。
@Configuration
@ComponentScan(basePackages = "com.keqing")
public class MyConfig {
@Bean
public People getPeople() {
return new People();
}
}
可以把xml中的配置全部搬迁到注解中来，这些配置都是等价的。
走到这一步，其实也是走到头了吧。Spring Boot能帮我们做的就是把这个注解配置类也帮我们屏蔽掉了，让我们使用的时候更加简单。但是，有些需要我们个性化配置的，我们还是需要配置文件去做的。
我们拿现在的全注解和以前的全xml配置比对，会发现不过是配置的大搬迁。该有的配置一个也不能少。注解当然多少也是带来了便利性，相对xml配置文件，节省了一些步骤和便于我们开发。但是注解的问题，我发现也没有xml配置那么直观，大量层层叠叠的注解更是看的人头疼，而且，注解也有架空方法名的问题，有了注解之后，方法名都显得没有作用了。这显然不是个好兆头。这是把java最底层面向对象思想的特性侵蚀掉了。
展望
后续的发展：
- 能不能解决注解带来的配置没有xml配置清楚的问题，能不能解决注解配置零散的问题。
- 注解消解了java中方法名称重要性的问题，能不能解决。
- Spring Boot能不能进一步发展，把“约定大于配置”这个思想进一步发挥到极致。其实，开发中还是有不少固定套路性质的代码没有被简化掉，比如开发web项目，其实，很有必要提出一套完整的解决方案出来精简代码。而不是让我们去整合Spring web，Mybatis，等等这些玩意，然后再编写整合之后，一些无聊的基础代码。其实，类似这种的问题，在gitee中有很多国内的开源项目就是什么后台管理系统，快速开发框架。我认为这才是下一步更加简单，智能的发展方向。比什么人工智能，机器学习靠谱多了。这也很符合上面技术演进的方向。因为高深的技术的发展方向必然是面向普通人开放的。从开始的博士等高学历人才才能从事开发工作，到现在技术普及到初高中就行。到将来技术肯定会演进到普通人拿来即用的程度，这是一个方向。
