菜鸟学习spring IOC有感
一、spring IOC思想引入
事实上对于刚開始学习的人来说，在学习IOC的时候确实有点困难，主要是掌握其思想方面存在一丢丢的障碍，可是假设可以跨过这个障碍，则可以高速掌握当中的思想了。单从字面上来讲，事实上IOC（反向控制）指的就是控制方向发生了变化。我们常常会遇到这句话：“实现必须依赖抽象，而不是抽象依赖实现。”尽管这句话表达了反向控制的概念，可是对于刚開始学习的人来讲，确实不是非常好理解。接下来我们就通过一些实例去理解这些内容的含义。
首先我们创建两个类，一个用于连接数据库，一个通过连接数据库实现获取数据库数据。
（1）通常我们都是先编写一个连接数据的类MysqlDatabaseConnection.java，当中getData()是为了获取数据库中的数据。
Public class MysqlDatabaseConnection{
……
public list getData(){
……
}
}
（2）在处理业务时，我们须要在连接数据库之后可以获得数据，因此在处理业务逻辑时建立一个DoBussiness的类，代码这样实现：
Public class DoBussiness{
Private MysqlDatabaseConnection db=new MysqlDatabaseConnection();
……
Public void getData(){
……
List list=db.getData();
}
}
这样一来，我们功能基本实现了。可是，我们细致分析会发现一个问题，但我的想换一个数据库连接时，发现必须重写数据库连接代码，比方说我们想用Oracle连接数据库时，得写一个连接Oracle的类。
Public class OracleDatabaseConnection{
……
public list getData(){
……
}
}
这样，我们就会发现，事实上我们的业务逻辑类DoBusiness是依赖于数据库的连接类，假设今天要用MySQL，明天换Oracle，后天来个DB2，What can we fucking do!假设我们公司刚開始是个小公司，随着公司的不断成长，业务不断丰富多变，那么要频繁改动我们的业务逻辑类就感觉太CD了。好吧，好像有点扯到了软件重构相关东西。
到这里，我们发现，这不是一个非常好地设计，由于每次业务的变化都要涉及大量程序改动。怎样设计一个模式，可以解决这样的问题呢。解决问题我们须要明确:我们是须要实现业务逻辑可以重用的设计模式。我们试着这样去考虑
1.编写一个通用的接口类DatabaseConnection。
Public interface DatabaseConnection{
……
Public List getData();
}
2.依据业务的不同编写详细负责数据库连接的类，比方说MysqlDatabaseConnection
Public class MysqlDatabaseConnection implements DatabaseConnection{
……
public LIst getData(){
……
}
}
3.编写业务逻辑类DoBusiness，该类仅仅针对接口实现编码，而不针对详细的实现类（这就是上面说的实现必须依赖与抽象）。
Public class DoBussiness{
Private DatabaseConnection db=new DatabaseConnection();
Public void setDatabaseConnection(DatabaseConnection db){
this.db=db;
}
……
Public void getData(){
……
List list=db.getData();
}
}
4.当我们要处理业务的时候，我们就能够依据我们想要的数据库连接来动态改变了。这个时候我们採取的措施是将数据库注入到业务逻辑类DoBusiness中（自己好好体会）。
Public class CallBussiness{
Private DoBussiness do=new DoBussiness();
……
Public void getData(){
……
//注入数据库，假设要改动了数据库，我们须要替换掉注入的数据库就能够了
Do. setDatabaseConnection(new MysqlDatabaseConnection());
List list=db.getData();
……
}
}
总结一下：我们看看控制怎样反转的。
|
|
|
起初，DoBusiness类是被各种数据库连接牵着鼻子走的，也就是被详细的数据库类控制。但是，当我们实现了数据库注入后，我们发现，情况发生了变化。
因为注入的突出贡献，给入驻颁了个奖叫“依赖注入突出贡献奖”。由此IOC又叫依赖注入DI。
二、依赖注入的三种实现方式。
1.接口注入，前面讲的就是接口注入。
2.set注入，在接受注入的类中定义一个Set方法，并在參数中定义须要注入的元素。
3.构造注入，在接受注入的类中定义一个构造方法，并在參数中定义须要注入的元素。
依照那种注入方式，各有说法，这里不一一讲述。
三、bean的管理。
Spring的核心容器实现了IOC，其目的是提供一种无侵入式的框架，为了实现之，在Spring中存在两个基本且很重要的包，org.springframework.beans和org.springframework,context。其代码中大量 存在Java反射机制。这两个包中，最重要的类是BeanFactory和ApplicationContext，ApplicationContext建立在BeanFactory基础上，并添加了一些比方国际化，事件传递等功能。
1.bean的基础知识
（1）bean的标志是由Id或者name来接界定的
（2）bean的class属性表明了bean的来源。
（3）bean的部署模式，有共享型和非共享型。
（4）bean重要的属性property
（5）bean的依赖depends-on能够在初始化使用bean之前，强制运行一个过多个bean的初始化。
（6）bean的生命周期能够从bean的定义、bean的初始化，和bean的销毁4个阶段。
2.bean的生命周期
（1）bean的定义一般通过配置文档的方式来定义Bean。
（2）bean的初始化有两种方式：init-method属性完毕，实现
org.springframework.beans.factory.InitializationBean接口。假设实现了该接口，那么全部必要的属性被BeanFactory设置后，会自己主动运行他的afterPropertiesSet（）方法。
（3）bean的使用有三种方式：第一种是BeanWrapper，另外一种是BeanFactory，第三种是ApplicationContext
（4）bean的销毁有两种方式：第一种通过destroy-method属性完毕，另外一种是实现org.springframework.beans.factory.DisposableBean接口，那么会自己主动运行destroy（）方法。
3.bean的自己主动装配
通过bean的autowire来指定bean自己主动装配，共同拥有5种模式自己主动装配。
（1）byName模式：通过bean属性名字进行自己主动装配，在Spring的配置文档XML中，查找一个与将要装配的属性相同名字的Bean。
（2）bytype模式：假设XML中正好有一个与属性类型一样的bean，就自己主动装配这个属性。
（3）constructor模式：依据构造函数的參数进行自己主动装配。
（4）autodetect模式：通过bean检查类的内部来选择constructor或bytpe。先constructor后bytype。
（5）no模式：不使用自己主动装配。
尽管有了自己主动装配能够降低开发者的输入工作，可是却非常难看出bean的每一个属性是否都设定完毕，所以不建议自己主动装配。若确实使用了自己主动装配，怎样检查bean的每一个属性是否设定完毕呢？请看Bean的依赖检查。
4.Bean的依赖检查
依赖检查有四种模式：simple,object,all,none。使用bean的dependency-check属性来指定。普通情况下，依赖检查和自己主动装配是结合使用的。
（1）simple模式：仅仅对基本类型，字符串和集合进行依赖检查。
（2）object模式：对依赖的对象进行依赖检查
（3）all模式：对所有属性进行依赖检查。
（4）none模式：不进行依赖检查。
<假设理解有误，还请指教>
