依赖注入的两种方式（spring ioc依赖注入有几种 每种区别，优缺点）

本文目录

• spring ioc依赖注入有几种 每种区别，优缺点
• 依赖注入的优点
• 什么是java的依赖注入
• 用javascript代码通俗的解释一下什么叫依赖注入
• 什么是依赖注入
• spring 中依赖注入的思想
• 请问下依赖注入的三种方式的区别
• 依赖注入究竟有什么好处

spring ioc依赖注入有几种 每种区别，优缺点

spring的核心思想是IOC和AOP，IOC-控制反转，是一个重要的面向对象编程的法则来消减计算机程序的耦合问题，控制反转一般分为两种类型，依赖注入和依赖查找，依赖什么？为什么需要依赖？注入什么？控制什么？依赖注入和控制反转是一样的概念吗？接触新的知识，小编的脑袋中全是大大的问号，不过没有关系，今天这篇博文，小编主要来简单的介绍一下在spring IOC中依赖注入的方法。

依赖注入和控制反转，目的是为了使类与类之间解耦合，提高系统的可扩展性和可维护性。我们可以从以下几个方面理解：a、参与者都有谁？b、依赖：谁依赖谁？为什么需要依赖？c、注入：谁注入谁？又注入了什么呢？d、控制反转：谁控制谁？控制什么？为什么叫反转呢？存在正转吗？

e、控制反转和依赖注入是同一个概念吗？我们需要弄明白上面的问题，这样对于控制反转和依赖注入的理解有大大的帮助。

首先：第一个问题，参与者都有谁？1）对象2）IOC/DI容器3）某个对象的外部资源

第二问题：依赖，谁依赖谁？为什么需要依赖？依赖嘛，很好理解的，对象依赖于IOC/DI容器，至于为什么要依赖呢？对象需要IOC/DI容器来提供对象需要的外部资源。

第三个问题：注入，谁注入谁？又注入了什么呢？显而易见是IOC/DI容器注入对象，注入了what呢？肯定注入的是某个需要的东西那就是注入对象所需要的资源，肯定不会注入无关紧要的内容，你说呢？

第四个问题：控制反转，谁控制谁？控制什么？为什么叫反转呢？存在正转吗？控制反转，控制什么？肯定是IOC/DI容器控制对象，主要是控制对象实例的创建，反转是相对于正向而言的，那么什么算是正向的呢？考虑一下常规情况下的应用程序，如果要在A里面使用C，你会怎么做呢？当然是直接去创建C的对象，也就是说，是在A类中主动去获取所需要的外部资源C，这种情况被称为正向的。那么什么是反向呢？就是A类不再主动去获取C，而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中。

第五个问题：控制反转和依赖注入式同一个概念吗？

依赖注入和控制反转是对同一件事情的不同描述，从某个方面讲，就是它们描述的角度不同。依赖注入是从应用程序的角度在描述，可以把依赖注入描述完整点：应用程序依赖容器创建并注入它所需要的外部资源；而控制反转是从容器的角度在描述，描述完整点：容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。

了解了这些基本的概念，弄明白她们之间的联系和区别，能够帮助我们更好的理解，接着小编来重点介绍一下依赖注入，在spring ioc中有三种依赖注入，分别是：

a、接口注入；b、setter方法注入；c、构造方法注入；

接着小编对这三种注入方式一一进行讲解，通过demo的讲解，希望能够帮助小伙伴们更好的理解，不足之处还请多多指教。接口注入

解释一下上述的代码部分，ClassA依赖于InterfaceB的实现，我们如何获得InterfaceB的实现实例呢？传统的方法是在代码中创建 InterfaceB实现类的实例，并将赋予clzB.这样一来，ClassA在编译期即依赖于InterfaceB的实现。为了将调用者与实现者在编译期分离，于是有了上面的代码。我们根据预先在配置文件中设定的实现类的类名(Config.BImplementation),动态加载实现类，并通过InterfaceB强制转型后为ClassA所用，这就是接口注入的一个最原始的雏形。

setter方法注入

setter注入模式在实际开发中有非常广泛的应用，setter方法更加直观，我们来看一下spring的配置文件：

依赖注入的优点

依赖注入的三种方式以及优缺点。博客分类： 设计模式 IOC 依赖注入是指在创建一个对象时，自动地创建它依赖的对象，并注入。大家都知道有三种途径来实现依赖注入，我这里总结一下这三种方式的优缺点：1.构造方法注入:优点：在构造方法中体现出对其他类的依赖，一眼就能看出这个类需要其他那些类才能工作。脱离了IOC框架，这个类仍然可以工作，POJO的概念。一旦对象初始化成功了，这个对象的状态肯定是正确的。缺点：构造函数会有很多参数（Bad smell）。有些类是需要默认构造函数的，比如MVC框架的Controller类，一旦使用构造函数注入，就无法使用默认构造函数。这个类里面的有些方法并不需要用到这些依赖（Bad smell）。2. Set方法注入：优点：在对象的整个生命周期内，可以随时动态的改变依赖。非常灵活。缺点：对象在创建后，被设置依赖对象之前这段时间状态是不对的。不直观，无法清晰地表示哪些属性是必须的。3. 方法参数注入：方法参数注入的意思是在创建对象后，通过自动调用某个方法来注入依赖。类似如下代码。

什么是java的依赖注入

Java的依赖注入：依赖注入，出自spring的IOC和DI，是Spring的两大特性之一（另一个AOP面向切面编程）以前对象使我们手动实例化，比如：Service层调用Dao层，需要Dao d = new Dao；但是这样会导致两个层之间的耦合性大大增强。而spring的IOC，反转控制，会在我们需要实例对象的时候，由spring容器为我们提供，并通过DI依赖注入来实现目标对象的获得，完成解耦操作。可以通过setter方法注入、构造注入、注解注入。

依赖注入是Spring的思想,在使用Spring进行开发时，可以将对象交给spring进行管理，在初始化时spring创建一批对象，当你需要用的时候只要从spring的容器中获取对象，而不用自己去new，当然在对象创建的时候可以注入另一个对象。比如A,B两个对象都由spring管理，A中持有对B的引用，那么spring在生成A对象的时候就已经吧B对象的一个实例给到A了，当你在A中用到B的时候直接使用就可以了。

用javascript代码通俗的解释一下什么叫依赖注入

首先必须了解依赖。依赖就是指B类要用A类的方法(或属性)，就称B依赖于A，那要调用方法肯定得有一个对象呀！

要解决从“没对象”到“有对象”的问题，有三种方式：

1. 程序猿嘛，自己new一个

2. 构造函数传入

3. setter函数传入

其中第一种自给自足，自己生产依赖的东西。。。。后两种是靠别人给的，别人把依赖的东西“注入”给你。后两种方式的过程就叫做“依赖注入”了。。。

总结，“依赖注入”就是需要什么对象，自己不去创建，而是把创建的过程放在了自己的外部。

有一些依赖注入框架，你可以声明需要的是什么对象，然后由框架来创建并注入给你。

什么是依赖注入

依赖注入是spring框架中的解耦的一种策略,称为DI或IOC(控制反转),主要有set方式（提供set和get方法)和constractor(构造方法)方式，它使得类与类之间以配置文件的形式组织在一起，而不是硬编码的方式，例如classA 中用到了classB如果写代码的话是new 一个classB,而用依赖注入的方式则是在applicationContext.xml里面写两个《bean id=“id1“ class=“A“》《property name=“B“ ref=“id2“》《/bean》《bean id=“id2“ class=“B“》《/bean》,就是在类A里原来需要new 的地方就不需要写了，

spring 中依赖注入的思想

依赖注入（Dependecy Injection）具体的讲：当某个角色需要另外一个角色协助的时候，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在spring中创建被调用者的工作不再由调用者来完成，因此称为控制反转。创建被调用者的工作由spring来完成，然后注入调用者因此也称为依赖注入。spring以动态灵活的方式来管理对象 ， 注入的两种方式，设置注入和构造注入。设置注入的优点：直观，自然构造注入的优点：可以在构造器中决定依赖关系的顺序。 依赖注入(DI)应该是实现控制反转(IOC)的一种方式而已，相应的还有依赖查找(Dependency Lookup)

请问下依赖注入的三种方式的区别

Type1 接口注入 我们常常借助接口来将调用者与实现者分离。如：public class ClassA {private InterfaceB clzB;public init() {Ojbect obj =Class.forName(Config.BImplementation).newInstance();clzB = (InterfaceB)obj;}……} 上面的代码中，ClassA依赖于InterfaceB的实现，如何获得InterfaceB实现类的实例？传统的方法是在代码中创建InterfaceB实现类的实例，并将起赋予clzB。 而这样一来，ClassA在编译期即依赖于InterfaceB的实现。为了将调用者与实现者在编译期分离，于是有了上面的代码，我们根据预先在配置文件中设定的实现类的类名，动态加载实现类，并通过InterfaceB强制转型后为ClassA所用。 这就是接口注入的一个最原始的雏形。 而对于一个Type1型IOC容器而言，加载接口实现并创建其实例的工作由容器完成，如J2EE开发中常用的Context.lookup（ServletContext.getXXX），都是Type1型IOC的表现形式。 Apache Avalon是一个典型的Type1型IOC容器。 Type2构造子注入 构造子注入，即通过构造函数完成依赖关系的设定，如：public class DIByConstructor {private final DataSource dataSource;private final String message;public DIByConstructor(DataSource ds, String msg) {this.dataSource = ds;this.message = msg;}……} 可以看到，在Type2类型的依赖注入机制中，依赖关系是通过类构造函数建立，容器通过调用类的构造方法，将其所需的依赖关系注入其中。 PicoContainer（另一种实现了依赖注入模式的轻量级容器）首先实现了Type2类型的依赖注入模式。 Type3设值注入 在各种类型的依赖注入模式中，设值注入模式在实际开发中得到了最广泛的应用（其中很大一部分得力于Spring框架的影响）。 在笔者看来，基于设置模式的依赖注入机制更加直观、也更加自然。Quick Start中的示例，就是典型的设置注入，即通过类的setter方法完成依赖关系的设置。 几种依赖注入模式的对比总结 接口注入模式因为具备侵入性，它要求组件必须与特定的接口相关联，因此并不被看好，实际使用有限。 Type2 构造子注入的优势： 1、“在构造期即创建一个完整、合法的对象”，对于这条Java设计原则，Type2无疑是最好的响应者。 2、避免了繁琐的setter方法的编写，所有依赖关系均在构造函数中设定，依赖关系集中呈现，更加易读。 3、由于没有setter方法，依赖关系在构造时由容器一次性设定，因此组件在被创建之后即处相对“不变”的稳定状态，无需担心上层代码在调用过程中执行setter方法对组件依赖关系产生破坏，特别是对于Singleton模式的组件而言，这可能对整个系统产生重大的影响。 4、同样，由于关联关系仅在构造函数中表达，只有组件创建者需要关心组件内部的依赖关系。对调用者而言，组件中的依赖关系处于黑盒之中。对上层屏蔽不必要的信息，也为系统的层次清晰性提供了保证。 5、通过构造子注入，意味着我们可以在构造函数中决定依赖关系的注入顺序，对于一个大量依赖外部服务的组件而言，依赖关系的获得顺序可能非常重要，比如某个依赖关系注入的先决条件是组件的DataSource及相关资源已经被设定。 Type3设值注入的优势 1、对于习惯了传统JavaBean开发的程序员而言，通过setter方法设定依赖关系显得更加直观，更加自然。 2、如果依赖关系（或继承关系）较为复杂，那么Type2模式的构造函数也会相当庞大（我们需要在构造函数中设定所有依赖关系），此时Type3模式往往更为简洁。 3、对于某些第三方类库而言，可能要求我们的组件必须提供一个默认的构造函数（如Struts中的Action），此时Type2类型的依赖注入机制就体现出其局限性，难以完成我们期望的功能。 可见，Type2和Type3模式各有千秋，而Spring、PicoContainer都对Type2和Type3类型的依赖注入机制提供了良好支持。这也就为我们提供了更多的选择余地。理论上，以Type2类型为主，辅之以Type3类型机制作为补充，可以达到最好的依赖注入效果，不过对于基于Spring Framework开发的应用而言，Type3使用更加广泛。

依赖注入究竟有什么好处

把对象生成放在了XML里定义，所以换一个实现子类将会变成很简单（一般这样的对象都是实现于某种接口的），只要修改XML就可以。这样甚至可以实现对象的热插拨。

依赖注入：

依赖注入就是Spring设计思想中重要的一部分,它是指Ioc或DI,是一个重要的面向对象编程的法则来削减计算机程序的耦合问题.控制反转还有一个名字叫做依赖注入（Dependency Injection）.简称DI.

IoC 亦称为 “依赖倒置原理”(“Dependency Inversion Principle“)。差不多所有框架都使用了“倒置注入(Fowler 2004)技巧，这可说是IoC原理的一项应用。SmallTalk，C++, Java 或各种.NET 语言等面向对象程序语言的程序员已使用了这些原理。

应用控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用，传递给它。也可以说，依赖被注入到对象中。所以，控制反转是，关于一个对象如何获取他所依赖的对象的引用，这个责任的反转。

依赖注入(Dependency Injection)和控制反转(Inversion of Control)是同一个概念。具体含义是:当某个角色(可能是一个Java实例，调用者)需要另一个角色(另一个Java实例，被调用者)的协助时，在 传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在Spring里，创建被调用者的工作不再由调用者来完成，因此称为控制反转;创建被调用者 实例的工作通常由Spring容器来完成，然后注入调用者，因此也称为依赖注入。

不管是依赖注入，还是控制反转，都说明Spring采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。在理解依赖注入之前，看如下这个问题在各种社会形态里如何解决:一个人(Java实例，调用者)需要一把斧子(Java实例，被调用者)。

(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:Java程序里的调用者自己创建被调用者。

(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。

(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。

第一种情况下，Java实例的调用者创建被调用的Java实例，必然要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合。

第二种情况下，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用。此时调用的代码面向接口编程，可以让调用者和被调用者解耦，这也是工厂模式大量使用的原因。但调用者需要自己定位工厂，调用者与特定工厂耦合在一起。

第三种情况下，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。事实上，调用者和被调用者都处于Spring的管理下，二者之间的依赖关系由Spring提供。

所谓依赖注入，是指程序运行过程中，如果需要调用另一个对象协助时，无须在代码中创建被调用者，而是依赖于外部的注入。Spring的依赖注入对调用者和被调用者几乎没有任何要求，完全支持对POJO之间依赖关系的管理。

依赖注入通常有两种:

1、设值注入。

2、构造注入。