spring三种注入方式比较

三种注入方式比较

接口注入：

接口注入模式因为具备侵入性，它要求组件必须与特定的接口相关联，因此并不被看好，实际使用有限。

Setter 注入：

对于习惯了传统 javabean 开发的程序员，通过 setter 方法设定依赖关系更加直观。

如果依赖关系较为复杂，那么构造子注入模式的构造函数也会相当庞大，而此时设值注入模式则更为简洁。

如果用到了第三方类库，可能要求我们的组件提供一个默认的构造函数，此时构造子注入模式也不适用。

构造器注入：

在构造期间完成一个完整的、合法的对象。

所有依赖关系在构造函数中集中呈现。

依赖关系在构造时由容器一次性设定，组件被创建之后一直处于相对“不变”的稳定状态。

只有组件的创建者关心其内部依赖关系，对调用者而言，该依赖关系处于“黑盒”之中。

总结

Spring使用注入方式，为什么使用注入方式，这系列问题实际归结起来就是一句话，Spring的注入和IoC（本人关于IoC的阐述）反转控制是一回事。

理论上：第三种注入方式（构造函数注入）在符合java使用原则上更加合理，第二种注入方式（setter注入）作为补充。

实际上：我个人认为第二种注入方式（setter注入）可以取得更加直观的效果，在使用工作上有不可比拟的优势，所以setter注入依赖关系应用更加广泛。

对象与对象之间的关系可以简单的理解为对象之间的依赖关系:

A类需要B类的一个实例来进行某些操作,比如在A类的方法中需要调用B类的方法来完成功能,叫做A类依赖于B类.

控制反转是一种将组件依赖关系的创建和管理置于程序外部的技术,由容器控制程序之间的关系,而不是由代码直接控制.

1.接口注入

public class ClassA {

private InterfaceB clzB;

public void doSomething() {

Ojbect obj = Class.forName(Config.BImplementation).newInstance();

clzB = (InterfaceB)obj;

clzB.doIt();

}

……

}

上面代码中,ClassA依赖于InterfaceB的实现,如何获得InterfaceB实现类的实例?传统的方法是在代码中创建InterfaceB实现类的实例,并将赋予clzB.这样一来,ClassA在编译期即依赖于InterfaceB的实现.为了将调用者与实现者在编译期分离,于是有了上面的代码.

我们根据预先在配置文件中设定的实现类的类名(Config.BImplementation),动态加载实现类,并通过InterfaceB强制转型后为ClassA所用,这就是接口注入的一个最原始的雏形.

public class ClassA {

private InterfaceB clzB;

public Object doSomething(InterfaceB b) {

clzB = b;

return clzB.doIt();

}

……

}

上面代码中,加载接口实现并创建其实例的工作由容器完成.

在运行期,InterfaceB实例将由容器提供.即使在IOC的概念尚未确立时,这样的方法也已经频繁出现在我们的代码中.

public class MyServlet extends HttpServlet {

public void doGet(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException {

……

}

}

HttpServletRequest和HttpServletResponse实例由Servlet Container在运行期动态注入.

2.Setter设置注入

基于设置模式的依赖注入机制更加直观,也更加自然.

public class ClassA {

private InterfaceB clzB;

public void setClzB(InterfaceB clzB) {

this.clzB = clzB;

}

……

}

3.构造器注入

public class DIByConstructor {

private final DataSource dataSource;

public DIByConstructor(DataSource ds) {

this.dataSource = ds;

}

……

}

构造器注入,即通过构造函数完成依赖关系的设定,容器通过调用类的构造方法将其所需的依赖关系注入其中.