Spring核心概念IoC

 在了解Spring IoC这个过程中，需要两点需要明白

1.了解代码中的耦合情况并且使用工厂模式解决耦合。

2.了解Spring IoC/DI的原理。

大家都知道JAVA是一种面向对象语言，在完成某个功能时需要编写很多的类协同完成工作。在接触Spring之前，相信对MVC都有了一定的概念，在MVC的三层架构设计时，通常JAVA类的调用顺序是Web层→业务层→持久层。也就是说在Web层需要创建并调用业务层对象，在业务层同样也需要创建和调用持久层的对象。

现在以一段代码来看。

//StudentAction.java
//Web层对象
public class StudentAction{
//创建业务层
StudentA studentA = new StudnetA();
public void printStudentname{
System.out.println("名字为:"+studentA.getName());
}
}

//StudentA.java
//业务层对象
public class StudentA{
//创建持久层对象
StudentDao studentdao = new StudentDao();
public String getName{
//调用持久层方法
return studentDao.getName();
}
}

这段代码相信已经写的很熟练了，在创建StudentA和StudentDao的时候都是通过new方法来定义的，此时呢可以说StudentAction依赖StudentA，StudentA依赖StudentDao。换句话说就是StudentAction如果调用StudentA必须要有StudentA出现，而StudentA调用StudentDao的时候又必须有StudentDao出现才可以。

类之间产生了依赖关系会产生一个问题，我们都知道JAVA是一种编译型语言，写好的.java是没法直接运行的，需要把编译成.class才可以在虚拟机中运行，对java源码修改以后，一定要重新编译一遍才可以继续运行。如果一个项目中.java有几百个，那么修改了一个.java后我们有可能还需要对其他有依赖关系的.java修改后才可以编译，例如当StudentA的代码修改了以后，可能是返回类型，有可能是功能变动，我们有可能也会需要修改StudentAction中的代码(不一定所有变动都需要修改)，当有几百个类文件的时候，那么当维护这个项目的时候，改了某个类的代码可能就会改的你头皮发麻，正所谓牵一发而动全身。大大降低代码可维护性。当StudentA有改动，StudentAction也需要改动的时候，我们把这种依赖情况叫代码耦合。

在写小的项目的时候，或许觉得这并没有什么问题，但是一旦项目比较大，有很多类很多文件的时候，就凉凉了，所以科比凌晨四点起来练球的时候，某程序猿还没开始睡觉。但是这些问题并不是不能解决，毕竟编程语言都发展了那么多年了，怎么也该有点进步了，解决这些问题的方法我们又亲切的称之为设计模式，大家都略有耳闻。解决耦合问题的设计模式就是大名鼎鼎的工厂模式(Factory)了。工厂模式说的直白点，就是求求你别在自家(依赖类当中)用那么多害人的new方法来定义了，我们建一个大工厂，然后在这个大工厂里面创建对象，然后有谁需要对象了就去工厂拿对象(社会主义万岁)，这个对象发生改变了，我们在工厂里把它修一修，改一改然后出厂，虽然皮囊还是一样，内在可能就已经变了，就像StudentA改变了，但是StudentAction是从工厂里找的StudentA中的对象，工厂负责加工好了直接给StudentAction，在StudentA变了，但是在StudentAction的眼里，StudentA却从来没变(因为不用在StudentAction中改它了)。下面举个例子，没代码不BB。

//先来个IStudentA接口
public interface IStudentA{}
//调用这个接口
public class StudentA implements IStudentA{

}
//造工厂
public class StudentAFactory(){
//工厂开始创建StudentA
public static IStudentA getInstance(){
return new StudentA();
}
}
public class StudentAction{
//使用工厂中产出的业务层对象，直接从工厂领，赋值给接口
IStudentA studentA = StudentAFactory.getInstance();
}

 

也就是说，StudentAFactory是创建StudentA的地方，谁想要对象了谁就去工厂领，本身不负责创建对象，当StudentA发生改变的时候也是工厂负责修改，StudentAction并不需要去修改代码。通过这个事例，说明了一个好的方法，我们不妨把创建对象这种工作放到一个三方的地方，这时候，工厂类就完美的承担了第三者的作用，也解决了耦合性过强的问题。方法是挺好，不过又产生了一个问题，开发的时候工作量又大了，还需要写工厂类，难受啊，这工厂还必须很全面，各种对象都要加工。

这时候Spring框架来了，它来了。

Spring有两大核心技术，控制反转（IoC）和依赖注入（DI），Spring是一个框架集，它既然是一个框架集肯定包含了很多组件，当然Ioc和DI算是基础组件了。它的功能就是代替大工厂，负责管理所有Java类，类对象的创建和依赖控制都又它负责了。

控制反转和依赖注入其实是一种东西，只是看待角度不同罢了，举个例子，当A类new一个B类出来的时候，那么控制权肯定在A类手中，毕竟A类来New别人嘛，这就是控制正转，我们万恶的操作来源。还是大工厂的思想，A类想要一个对象，他想来找B了，但是A并不直接找B去控制它，A使用B的实例由Spring创建的时候，那么这个控制权就由Spring来掌握了，这就是控制反转，所谓依赖注入就是最早的时候A中去New一个B出来，A很依赖B的，但是现在A不去依赖B了，A依赖Spring，Spring再当第三者注入B中，就完成了。Spring Ioc/DI更直观又叫容器，当某个类需要对象就会去找大工厂(容器)然后就给它提供，就跟个容器似的，可以放很多东西，谁需要什么就从中取什么，这么说够直观了吧。

Spring容器中都可以有什么类使用呢，这需要预先定义在Spring的配置文件中，例如有两个类A和B，在A类中使用到了B，那么在配置文件中定义好这种关系，即可由Spring自动将B的实例注入A了。就跟A去大工厂要对象，它也得提前跟工厂说想要啥对象吧，然后工厂根据A的需求给它找了个对象，然后A再去直接取对象就行了。不过去对象也不是白取，在这种注入中也是有条件的，首先类要符合JavaBean的定义规范，在A类中需要定义对B类的赋值的setter方法，这就是Spring对管理的类的唯一要求了。