反向控制和面向切面编程在Spring的应用

针对传统的J2EE架构方案常常无法让人满意：程序过于复杂，难以测试和维护成本高。根据企业实际需求，本文探讨了一种轻量级的J2EE应用框架Spring ，它用更加轻量、更加灵活的基础设施取代了EJB。在此对Spring背后的反向控制原理和面向切面编程技术进行了比较深入研究，并与传统实现进行对比，显示了这种框架具有大大降低开发成本，可测试等优点。

　　关键词 Spring；反向控制；面向切面编程；POJO；依赖注入
1、Spring IoC 1.1 反向控制原理

　　反向控制是Spring框架的核心。但是，反向控制是什么意思？到底控制的什么方面被反向了呢？2004年美国专家Martin Fowler发表了一篇论文《Inversion of Control Containers and the Dependency Injection pattern》阐述了这个问题，他总结说是获得依赖对象的方式反向了，根据这个启示，他还为反向控制提出了一个更贴切的名字：Dependency Injection(DI 依赖注入)。

　　通常，应用代码需要告知容器或框架,让它们找到自身所需要的类,然后再由应用代码创建待使用的对象实例。因此，应用代码在使用实例之前，需要创建对象实例。然而，IoC模式中,创建对象实例的任务交给IoC容器或框架(实现了IoC设计模式的框架也被称为IoC容器)，使得应用代码只需要直接使用实例，这就是IoC。相对IoC 而言，“依赖注入”的确更加准确的描述了这种设计理念。所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。

　　1.2 IoC在Spring中的实现

　　任何重要的系统都需要至少两个相互合作的类来完成业务逻辑。通常，每个对象都要自己负责得到它的合作（依赖）对象。你会发现，这样会导致代码耦合度高而且难于测试。使用IoC，对象的依赖都是在对象创建时由负责协调系统中各个对象的外部实体提供的，这样使软件组件松散连接成为可能。下面示意了Spring IoC 应用，步骤如下：

　　（1）定义Action接口，并为其定义一个execute方法，以完成目标逻辑。多年前，GoF在《Design Pattern：Elements of Reusable Object-Oriented Software》一书中提出“Programming to an Interface，not an implementation”的原则，这里首先将业务对象抽象成接口，正是为了实施这个原则。

　　（2）类UpperAction实现Action接口，在此类中，定义一个String型的域message，并提供相应的setter和getter方法，实现的execute方法如下：

public String execute (String str) { 　return (getMessage () + str).toUpperCase () ; }

　　（3）编写Spring配置文件（bean.xml）

＜beans＞ ＜bean id="TheAction" class="net.chen.spring.qs.UpperAction"＞ ＜property name="message"＞ ＜value＞HeLLo＜/value＞ ＜/property＞ ＜/bean＞ ＜/beans＞

　　（4）测试代码

public void testQuickStart () { 　ApplicationContext ctx=new 　FileSystemXmlApplicationContext ("bean.xml"); 　Action a= (Action) ctx.getBean ("TheAction"); 　System.out.println (a. execute ("Rod Johnson")); }

　　上面的测试代码中，我们根据"bean.xml"创建了一个ApplicationContext实例，并从此实例中获取我们所需的Action实现，运行测试代码，我们看到控制台输出：

…… HELLO ROD JOHNSON

　　仔细观察一下上面的代码，可以看到：

　　（1）我们的组件并不需要实现框架指定的接口，因此可以轻松的将组件从Spring中脱离，甚至不需要任何修改，这在基于EJB框架实现的应用中是难以想象的。

　　（2）组件间的依赖关系减少，极大改善了代码的可重用性。Spring的依赖注入机制，可以在运行期为组件配置所需资源，而无需在编写组件代码时就加以指定，从而在相当程度上降低了组件之间的耦合。

　　Spring给我们带来了如此这般的好处，那么，反过来，让我们试想一下，如果不使用Spring框架，回到我们传统的编码模式，情况会是怎样呢？

　　首先，我们必须编写一个配置文件读取类，以实现Message属性的可配置化。

　　其次，得有一个Factory模式的实现，并结合配置文件的读写完成Action的动态加载。于是，我们实现了一个ActionFactory来实现这个功能：

public class ActionFactory { 　public static Action getAction (String actionName) {Properties pro = new Properties (); 　try { 　　pro.load (new FileInputStream ("config.properties")); 　　String actionImplName =(String)pro.get(actionName); 　　String actionMessage =(String) pro.get (actionName+"_msg"); 　　Object obj =Class.forName (actionImplName).newInstance (); 　　BeanUtils.setProperty(obj,"message",actionMessage); 　　return (Action) obj; 　} catch (FileNotFoundException e) { 　　…… 　} }

　　配置文件则采用properties文件形式如下所示：

TheAction=net.chen.spring.qs.UpperAction TheAction_msg=HeLLo

　　测试代码也作相应修改。现在不论实现的好坏，总之通过上面新增的多行代码，终于实现了类似的功能。如果现在有了一个新的需求，这样这个ActionFactory每次都新建一个类的实例，显然这对系统性能不利，考虑到我们的两个Action都是线程安全的，修改一下ActionFactory，保持系统中只有一个Action实例供其它线程调用。另外Action对象创建后，需要做一些初始化工作。修改一下ActionFactory，使其在创建Action实例之后，随即就调用Action.init方法执行初始化。Action的处理这样就差不多了。下面我们来看看另外一个Factory

　　……

　　往往这些系统开发中最常见的需求，会导致我们的代码迅速膨胀，而Spring IoC的出现，则大大缓解了这样的窘境。通过以上实例，可以看出，Spring IoC为我们提供了如下几方面的优势：

　　（1）应用组件不需要在运行时寻找其协作者，因此更易于开发和编写应用；

　　（2）由于借助于IoC容器管理组件的依赖关系，使得应用的单元测试和集成测试更利于展开；

　　（3）通常，在借助于IoC容器关系业务对象的前提下，很少需要使用具体IoC容器提供的API，这使得集成现有的遗留应用成为可能。

　　因此，通过使用IoC能够降低组件之间的耦合度，最终，能够提高类的重用性，利于测试，而且更利于整个产品或系统集成和配置。