spring中依赖注入与aop讲解

一、依赖注入

这个属于IOC依赖注入，也叫控制反转，IOC是说类的实例由容器产生，而不是我们用new的方式创建实例，控制端发生了改变所以叫控制反转。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<? 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:tx = "http://www.springframework.org/schema/tx"   xmlns:aop = "http://www.springframework.org/schema/aop"   xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-2.0.xsd   http://www.springframework.org/schema/tx   http://www.springframework.org/schema/tx/spring-tx-2.0.xsd   http://www.springframework.org/schema/aop   http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">     < bean   id = "dataSource"   class = "org.apache.commons.dbcp.BasicDataSource" >    < property   name = "driverClassName"   value = "com.microsoft.sqlserver.jdbc.SQLServerDriver"   />    < property   name = "url"   value = "jdbc:sqlserver://192.168.2.123:1433;DatabaseName=storage"   />    < property   name = "username"   value = "sa"   />    < property   name = "password"   value = "111"   />   </ bean >   < bean   id = "sqlMapClient"   class = "org.springframework.orm.ibatis.SqlMapClientFactoryBean" >    < property   name = "configLocation"   value = "classpath:sqlMapConfig.xml"   />    < property   name = "dataSource"   ref = "dataSource"   />   </ bean >

当我们使用实例时直接从容器中去就行了，就像上面的
<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">  
  <property name="configLocation" value="classpath:sqlMapConfig.xml" />
  <property name="dataSource" ref="dataSource" />
</bean>
sqlMapClient bean中使用到了dataSource 这个bean 我们直接写上beanID dataSource就可以引用到org.apache.commons.dbcp.BasicDataSource的实例了
这是在配置文件中，如果在类中我们通过容器提提供的方法获得这个配置文件的信息，在通过方法从容器中取出需要的类的实例就可以了。

二、这里什么是aop呢

AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向切面编程。

可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。

AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。

  举例：

假设有在一个应用系统中，有一个共享的数据必须被并发同时访问，首先，将这个数据封装在数据对象中，称为Data Class，同时，将有多个访问类，专门用于在同一时刻访问这同一个数据对象。

   图可以说明。内部实现包括采用动态代理模式和cglib的内容。

    IOC其原理是基于OO设计原则的The Hollywood Principle：Don't call us, we'll call you（别找我，我会来找你的）。也就是说，所有的组件都是被动的（Passive），所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。

   dataSource中property就是采用依赖注入。

   不知道你是否理解，可以看一本书《spring in action》

下面摘自百度百科的说法更形象：

IoC就是IoC，不是什么技术，与 GoF一样，是一种 设计模式。

Interface Driven Design接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执 行：

AInterface a = new AInterfaceImp(); 

这样一来，耦合关系就产生了，如：

Class A

{

    AInterface a;

    A() { }

    aMethod()

    {

        a = new AInterfaceImp();

    }

}

 

ClassA与AInterfaceImp就是依赖关系，如果想使用AInterface的另外一个实现就需要更改代码了。当然我们可以建立一个Factory来根据条件生成想要的AInterface的具体实现，即：

InterfaceImplFactory

{

    AInterface create(Object condition)

    {

        if(condition = condA)

        {

            return new AInterfaceImpA();

        }

        elseif(condition = condB)

        {

            return new AInterfaceImpB();

        }

        else

        {

            return new AInterfaceImp();

        }

    }

}

 

表面上是在一定程度上缓解了以上问题，但实质上这种代码耦合并没有改变。

通过IoC模式可 以彻底解决这种耦合，它把耦合从代码中移出去，放到统一的XML 文件中，通过一个容器在需要的时候把这个依赖关系形成，即把需要的接口实现注入到需要它的类中，这可能就是“依赖注入”说法的来源了。

IOC模式，系统中通过引入实现了IOC模式的IOC容器，即可由IOC容器来管理对象的生命周期、依赖关系等，从而使得 应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过 文本的配置文件进行 应用程序组件间相互关系的配置，而不用重新修改并编译具体的代码。

当前比较知名的IOC容器有： Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。

在上面的几个IOC容器中，轻量级的有Pico Container、Avalon、Spring、HiveMind等，超重量级的有EJB，而半轻半重的有容器有JBoss，Jdon等。

可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在 XML文件中给出定义的，然后利用Java 的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是 把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。

IoC中最基本的Java技术就是“反射”编程。反射又是一个生涩的名词，通俗的说反射就是根据给出的类名（字符串）来生成对象。这种编程方式可以让对象在生成时才决定要生成哪一种对象。

反射的应用是很广泛的，象Hibernate、Spring中都是用“反射”做为最基本的技术手段。

在过去，反射编程方式相对于正常的对象生成方式要慢10几倍，这也许也是当时为什么 反射技术没有普通应用开来的原因。但经SUN改良优化后，反射方式生成对象和通常对象生成方式，速度已经相差不大了（但依然有一倍以上的差距）。

 

 

 

 

 

 

 

 

 

 

 

转载于:https://www.cnblogs.com/wang3680/p/3482716.html