在本文的开始之前，先给大家介绍一个概念“依赖”。

什么是依赖呢？

简单的说，就是A组件需要调用B组件，B组件需要调用C组件，C组件需要调用D组件…..这种调用称为：依赖！

在最早的应用程序中，依赖关系时通过new关键字来实现的。A组件依赖B组件，就是在A组件中显示的new一个B组件。缺点：

    1、硬编码，耦合性强，难以维护。A组件只需要B组件中的方法，不必关心B组件的创建问题！

    2、频繁的创建对象，导致系统开销增大。

上面的这种缺点，直接催生了‘工厂模式’。

    在工厂模式中，A组件依赖B组件时，A组件不再负责创建B组件，B组件的创建由工厂完成，A组件只需要跟工厂要就够了。

从代码角度来看，可以把JNDI查找看做是典型的工厂模式。

把Context当做是工厂，jndi当做是被生产的产品。

    Context ctx=new InitialContext();

    Xxx  xx=(Xxx)ctx.lookup(jndi);

        而实际上，JNDI并不是工厂模式！那么到底是谁生产的这些产品呢？正确答案是：我们通常用XML的方式来配置对象，而真正创建这些对象的是一个用服务器、EJB容器这类工厂，只不过他们都是功能异常强大的工厂。

       当应用服务器、EJB容器把各种对象（如：数据源，JMS消息目的、EJB实例）创建出来之后，接下来就是给这些对象起个可以全局访问的名字供外界访问。这个过程被称作是：JNDI绑定。

       而通过JNDI查找应用服务器，EJB容器中时，就相当于客户端向工厂要他们所依赖组件的过程。

       再后来，Spring框架提出依赖注入的概念。

       当A组件依赖B组件时，开发者通过XML文件或者Annotation进行配置，而由容器来负责实例化B组件，并将B组件注入到A组件中，这就是所谓的依赖注入。

       很明显，依赖注入是建立在工厂模式的基础上又向前走了一步。使用依赖注入后，当A组件依赖B组件时，A组件不再需要向工厂要B组件，而是由容器主动将B组件注入到A组件中。 

       依赖注入比JNDI查找更先进，更有利于代码解耦。

关于依赖注入，本文主要从以下两方面讲解：资源依赖、EJB依赖

1.资源依赖    @Resource@Resources

如：A组件依赖于某个数据源资源，某个JMS消息目的等

2.EJB依赖   @EJB@EJBs

如：A组件依赖于某个EJB。

（ 一）EJB注入

       EJB注入主要靠位于javax.ejb包下的@EJB@EJBs两个Annotation来提供。

       @EJB既可以用于修饰Bean实现类的成员变量，也可以用于修饰Bean类setter方法。EJB容器的依赖注入会自动将对应的EJB注入该Field或setter方法中。

使用@EJB时，可以指定如下属性：

beanInterface：该属性指定被注入EJB所实现的接口。该属性通常用于区分所引用的Bean是远程调用Bean，还是本地Bean

name：用于指定被注入的Bean在JNDI ENC中的注册项名称，该名称在不同应用服务器中可能存在差异。

beanName：该属性指定被注入EJB的名称，用起来比较方便。其值与被注入Bean中@Stateless.name  @Stateful.name 或ejb-jar.xml中<ejb-name…>元素所指定的值相等。

mappedName：指定被注入EJB的JNDI名，但由于全局JNDI名与应用服务器厂商有关系，因此设置该属性可能降低应用的可移植性。

本例将介绍：本地调用的EJB注入远程调用的EJB中，从而间接的让本地EJB也可以对外提供服务。

本地调用EJB，业务接口

@LocalPublic interface Hello{	Public String hello(String name);}

本地调用EJB，实现类

@Stateless(name="Hello")Public class HelloBean implements Hello{	Public String hello(String name){		Return name+"，现在时间："+new java.util.Date();	}}

新的EJB，业务接口

@RemotePublic interface CallHello{	String callHello(String name);}

接下来定义新的EJB，用于调用上面的Hello EJB。（此时不需要JNDI查找，而是通过依赖注入的方式）

新的EJB，实现类

@Stateless(mapped="CallHello")Public class CallHelloBean implements CallHello{	@EJB(beanName="Hello")//修饰hello实例变量，EJB容器就会将该应用中表示名为Hello的EJB注入到hello实例变量。	Private Hello hello;	Public String callHello(String name){			Final String str="调用Hello EJB成功，返回值：";		String result=hello.hello("nihao,zhongguo");		System.out.println(str+result);		Return str+result;		}}

编译上面的4个Java文件，后将它们打包成一个EJB的JAR包，后部署到服务器中。

       总结：本例中，整个应用的EAO层是Local EJB，而应用业务逻辑层的Session Bean则需要依赖这些EAO EJB。因此，会采用依赖注入将这些EAO注入到Session Bean中。

       至于Session Bean到底定义成Remote？还是Local？这取决于应用是否需要让业务逻辑层提供远程访问支持。

（二）资源注入

 用法与@EJB基本相同，也是由于修饰Bean实现类的成员变量或setter方法。

使用@Resource Annotation时可使用如下属性：

String mappedName：指定该资源JNDI应用名称

String name：该属性指定外部资源JDNI ENC名称，该名称在不同的应用服务器中可能有小小的变化

Boolean  shareable：该属性指定该资源是否可以共享

Class type:该属性执行资源对应的Java类名 

本例将介绍：

@Stateless(mappedName="Cmt2")@TransactionManagement(TransactionManagementType.CONTAINER)@TransactionAttribute(TransactionAttributeType.REQUIRED)public class Cmt2Bean implements Cmt2{	@Resource(mappedName="javaee")	private  DataSource ds=null;		@Resource	private SessionContext sessCtx;		public void insert(){		try {			Connection conn=ds.getConnection();			Statement stmt=conn.createStatement();			int result=stmt.executeUpdate("inset into TB_USER "+"value(null,'新用户','zhaolijing')");			System.out.println(result);			stmt.close();			conn.close();		} catch (SQLException e) {			e.printStackTrace();			sessCtx.setRollbackOnly();		}	}}

       上面例子中，@Resource都是依赖注入的Annotation。

       @Resource(mappedName="javaee")，告诉EJB容器将JNDI为javaee的数据源注入到该成员变量，因此该Bean实现类中无须对ds成员变量执行初始化，后面却可以通过它来访问数据库。

总结：本文主要讲述了“依赖注入”的由来，同时从两方面进行讲解：资源依赖、EJB依赖

1.早先的‘依赖’可以理解为‘调用关系’，A调用B，则在A中new B。

2.后来，出现了“工厂模式”，使得创建B的过程，交给工厂来做。A只需要跟工厂‘要’B就可以了。

3.后来，出现了‘容器’，创建B的过程，交给容器（是一个异常强大的工厂）来做。然后给B提供一个全局访问的名字，这个过程叫做：JNDI绑定。然后A通过查找，可以使用B。

4.再后来，出现了“依赖注入”， 由容器来负责实例化B，并将B注入到A中，这就是所谓的依赖注入。这样的好处在于，当A使用B时，A不再需要向工厂/容器要B，而是由容器主动将B注入到A中。 

依赖注入比JNDI查找更先进，更有利于代码解耦。