Spring容器的理解

控制反转（IOC，Inversion Of Contorl）和依赖注入（DI，Dependency Injection）

　　IOC是一个宽泛的概念：对某事物的控制权由A转移到B。

　　DI是实现IOC的一种实现，实现的方式是：A依赖X，B就通过注入的方式将X给A，而不需要A自己去获取或者创建X。在这个情况下，X的控制权就由A转移到B这里了，也就是实现了IOC。

　　（ps：DL，Dependency Lookup，依赖查找也是IOC的一种实现，如spring中的context.getBean(XX.class)）

　　举个生活中的例子：前台收到你的快递，而你在工位上写代码。一般这个时候，自己会停下手里的工作，到前台把快递拿回来。而对于使用了依赖注入的情况就是，你将拿快递的控制权交给前台，让她拿过来给你，这时候自己就方便多了。

　　再举一个代码相关的例子（为了简化，没有使用接口）：

Shell shell = new Shell();
Wheel wheel = new Wheel();
Car car = new Car(shell, wheel);car.run();

　　需要什么，就自己去创建什么，最后都装配到一起使用，核心的业务逻辑就是一行 run，却多写了好多行装配代码（依赖关系复杂的情况下代码更多），而使用了DI的情况，配置好了依赖关系之后，在代码中：

@Autowired
Car car;

　　也就是，在代码中就可以省略了处理依赖关系的代码，可以使开发人员更加专注于业务逻辑。

　　其实，程序的复杂度并没有凭空消失，该new的还是要new，该装配的还是要装配。只是原来混杂在业务逻辑中，使用DI之后就转移到了容器中而已。有人可能会说，实现“转移”不需要用Spring容器，大可以自己写一个工具类，里面专门用来new对象、装配对象，然后通过反射的方式将装配好的对象注入（或者通过业务类的setter注入所需的对象）到业务代码中。这样做绝对没问题，这样做变相地就是自己实现了一个容器功能，多麻烦。既然有个现成的Spring容器就直接用了吧。

　　可以看出使用DI的优势就是方便。反过来思考，在一个spring应用中，假如让你不使用容器注入，自己可以实践一下，就知道手动处理依赖关系有多麻烦了。