摘要
J2EE编程正在变得越来越复杂。J2EE已经发展为一个API、复杂化的编程和配置的复杂网络。为了应对这种复杂性，新的框架和方法不断涌现。这些框架高度依靠于一个称为IoC（Inversion of Control，反向控制）的概念。本文将探讨这种方法的一些特性和优点，因为这种方法与J2EE编程相关，而且可以使J2EE编程变得更轻松。
简介
马克·吐温的一句话常被引用：“……关于我死亡的报道是一种夸张。”现在已经出现了很多关于.Net的流言，以及认为J2EE API的复杂性无法克服和EJB作为一种组件架构即将灭亡的流行极客(geek)文化。从学术或者只是想像的立场来看，这没什么大不了的，但事实是J2EE/EJB API已经经历了一场达尔文式的进化。具有DCOM或CORBA项目经验的读者会明白我的意思。过去，人们都乐于听闻EJB组件模型的美好前景。实际情况是，人们在与J2EE相关的各个方面都投入巨大。公布抛弃以前的所有工作并重新组织，这种想法看起来也许有理，但是它并没有建立在良好的业务洞察力之上。EJB继续发展，而术语、实践和框架也随之涌现(sPRing up)，它们弥补了J2EE API的不足。我说的不是“Spring出现(up)”，对吧？
我是一名顾问，职责是帮助构建大型的分布式应用程序，而且通常是J2EE应用程序。因此，我有机会亲历许多项目的整个生命周期。另外我还能够将我从一个刚刚完成的项目中刚刚学到的东西直接带入一个全新的项目。从某种意义上说我的“自然选择”过程加快了。我可以说最近Spring（更具体地说就是IoC，即反向控制）已经越来越多地融入到我的项目中了。在本文中，我将从支持或增强J2EE项目的角度来探讨Spring。更确切地讲，Spring框架能够标准化许多J2EE最佳实践，还能同类化(homogenize)许多无处不在的J2EE模式。接下来我们将浏览Spring庞大体系中的一小部分内容，重点介绍（依我浅见）能够帮助改进J2EE应用程序的功能。
IoC简介
一般来说，IoC是一种治理类之间关联的技术。没错，就这么简单！任何人都不是孤立的，对于各个对象来说也是如此。应用程序中的对象是相互依靠的。通过编程方式来表现这种依靠性通常既冗长又轻易出错。好的IoC框架将声明式地（通过一个xml配置文件）而不是编程式地（这种方式的可靠性较差）——串连起应用程序之间的相互依靠性。
自由使用接口是IoC开发的一个主要方针。接口编程大大提高了应用程序的灵活性，从而增强了声明式的关联。接口实现是通过IoC配置在运行时声明的，这样就能够在不影响或少影响实际应用程序代码的情况下“重建(rewire)”关联。这在各种IoC框架中是反复提及的一个主题，一般而言，也是应该遵循的良好实践。
一个小例子
我喜欢通过例子来更快地理解概念。下面就是运用了IoC的一组例子；您将看到，这些例子的复杂性是逐递增的。大多数人在一开始使用IoC容器时都是利用其依靠注入(inject dependency)功能——即，声明式地将对象关联起来。利用IoC有助于创建更整洁的代码，如有必要重建对象之间的关联，一般来说对于这些代码也会更灵活、更轻易。IoC的优点远不止依靠注入，而其扩展功能确是以依靠注入程序为起点的。
我们将从构建简单的依靠注入例子开始。第一个例子用于阐明已经提及的两个概念。第一个概念是IoC在运行时构建和关联对象的能力，第二个是与接口编码相结合而产生的灵活性。首先假定架构师递交了图1所示的UML。
图1. 接口可插性
这个小例子表示一个温度测量系统。几个传感器对象属于不同的类型，但都实现了ProtocolAdapterIfc接口，因此在将它们插入TemperatureSensor对象时，它们是可互换的。在需要TemperatureSensor时，系统中的某个实体必须知道要生成并与该传感器对象关联的ProtocolAdapterIfc的具体类型。在本例中，该传感器可基于命令行参数、数据库中的行或通过属性文件进行配置。本例还不足以造成挑战或展示一个复杂框架，但它足以阐明IoC基础。
但是，想象一下：在一个相当复杂的应用程序中这种情况屡屡发生，而您还希望能动态地——至少要在外部——改变对象关联。假设有一个DummyProtocolAdapter，它总是返回42这个值，使用它来进行测试。为什么不提供一个单个的统一框架？——让开发人员能够依靠该框架，以一种一致的、外部配置的方式建立类之间的关联，并且不引起工厂单元素类(factory singleton classe)的异常增加。这听起来可能没什么大不了，但它要依靠于IoC的简单性。
我们使用一个TemperatureSensor类，它与一个实现ProtocolAdapterIfc接口的类有关联。TemperatureSensor将使用该委托类来获得温度值。如UML图所示，在实现ProtocolAdapterIfc并且随后可用于该关联的应用程序中有若干个类。我们将使用IoC框架（在本例中是Spring）来声明要使用的ProtocolAdaperIfc的实现。Spring将在运行时建立关联。我们先来看XML代码，它将实例化TemperatureSensor对象并将一个ProtocolAdapterIfc实现与它关联起来。该代码如下所示：
<bean id="tempSensor"
class="yourco.project.sensor.TemperatureSensor"
<property name="sensorDelegate"
<ref bean="sensor"/
</property
</bean
<!-- Sensor to associate with tempSensor --
<bean id="sensor" class="yourco.project.comm.RS232Adapter"/
看了这些代码之后，对于其目的就应该非常清楚了。我们配置Spring来实例化TemperatureSensor对象，并将其与RS232Adapter相关联，作为实现ProtocolAdapterIfc接口的类。若想改变已经与TemperatureSensor关联的实现，惟一需要更改的就是sensor bean标记中的class值。只要实现了ProtocolAdapterIfc接口，TemperatureSensor就不再关心关联了什么。
将这应用于应用程序相当简单。我们必须先接入Spring框架，将它指向正确的配置文件，然后根据名称向Spring索取tempSensor对象的实例。下面是相应的代码：
ClassPathXmlapplicationContext appContext =
new ClassPathXmlApplicationContext(
new String[]
{ "simpleSensor.xml" });
BeanFactory bf = (BeanFactory) appContext;
TemperatureSensor ts = (TemperatureSensor)
bf.getBean("tempSensor");
System.out.println("The temp is: "+
ts.getTemperature());
可以看出，这些代码并不是非常难。首先是启动Spring并指定要使用的配置文件。接下来根据名称（tempSensor）引用Bean。Spring使用这样一种机制：基于simpleSensor.xml文件的描述创建该对象并与其他对象关联。它用于注入依靠性——在本例中，通过将它作为一个参数传递给sensorDelegate()方法而实例化RS232Adapter对象并将其与TemperatureSensor对象关联。
比较起来，使用编程式java完成这一任务也不是很难。如下所示：
TemperatureSensor ts2 = new TemperatureSensor();
ts2.setSensorDelegate(new RS232Adapter());
纯粹主义者或许会认为实际上这是更好的方法。代码行数少，并且可读性可能更强。确实如此，但这种方法的灵活性要小得多。
可以随意换入和换出不同层中不同对象的不同实现。例如，若Web层中的组件需要来自新业务对象的额外的功能，您只需将该业务对象与Web层对象相关联，就像上面TemperatureSensor例子中的做法。它将被“注入”到Web对象中以随时使用。
能够重新配置整个应用程序的结构，意味着可以轻松更改数据源。比如说，或者为不同的部署场景创建不同的配置文件，或者为测试场景创建更有用的、不同的配置文件。在测试场景中可能会注入实现接口的模拟对象，而不注入真正的对象。稍后我们将介绍一个这样的例子。
上面所述的例子可能是依靠注入的最简单形式。利用相同的策略，我们不仅能够关联不同的类，还能够在类中安装属性。诸如字符串、整数或浮点数之类的属性，只要具有JavaBean样式的存取器，就可以通过Spring配置文件将它们注入类中。我们还可以通过构造函数来创建对象和安装属性或bean引用。其语法只比通过属性进行设置稍稍复杂一些。
所有这一切都是利用一种灵活的声明性配置完成的。无需更改代码，建立依靠关联的所有艰难任务都由Spring来完成。
Spring--标准化的定位器模式
我一直将服务定位器模式视作良好的J2EE规范的主要组成部分。对于不熟悉这一术语的人来说，可以这样理解它：我们一般认为典型的J2EE应用程序由若干层组成。通常有Web层、服务层（EJB、JMS、WS、WLS控件）以及数据库。一般来说，完成某一请求所需的“查找”服务中都包含了一些方法。Service Locator（服务定位器）模式认为，将这些方法包装在某种隐藏了生成或查找给定服务的复杂性的工厂类中是一个好主意。这减少了JNDI或只会造成Web层操作类混乱的其他服务产品代码的增加。在Spring出现以前，这通常是由经过考验证实可靠的(tried-and-true)Singleton类来实现的。Singleton/Locator/Factory模式可以描绘为：
图2. 定位器模式的顺序图
这是对散布在整个Web控制器代码中的增加的JNDI查找代码的一个巨大改进。它被巧妙地隐藏在工厂内部的协作类中。我们可以使用Spring来改进这一术语。此外，该解决方案将适用于EJB、Web services、异步JMS调用，甚至还有基于WLS控件的服务。由Spring实现的这种定
