开源技术：将系统移植到Spring

   现在在spring-objectregistry.xml文件中定义的对象，对于WEB-INF/SpringMVC-servlet.xml中定义的那些对象是可见的。
    这样做就产生了另外一个问题：MVC层将spring-objectregistry.xml和SpringMVC-servlet.xml文件装载到一个ApplicationContext中。对象注册将spring-objectregistry.xml装载到一个不同的ApplicationContext中。这两个ApplicationContext分别在各自的环境中，默认情况下，它们彼此看不到bean的定义。

    定义在spring-objectregistry.xml文件中的对象被依次注册2次：一次是通过MVC层，然后是对象注册。这样，spring-objectregistry.xml文件中单态对象实际上已经不在是单个的了。在例子代码中这个都是无状态对象，但在一个稍大的应用中一些单个对象可能确实要保持状态。如果我不仅仅只是装载一次这些对象的话，可能会有一个同步的问题。就像如果一个对象要执行一些以前的资源优化(resource-intensive)的操作,那我的应用的性能将有所损失(译者：因为2个对象不一致)。

    我的第一个反应就是重构那些ObjectRegistry中不需要的代码。那是一个简单的事情，但这是一个学习的过程。假设这是一个大的工程，其中移除注册类不是个一次就能做好的任务，我决定留着它并且解决怎样让2个环境工作的问题。

    简而言之，我需要一些途径把ObjectRegistry (spring-objectregistry.xml)中的对象暴露给那些在web层(WEB-INF/SpringMVC-servlet.xml)中的对象。Spring的解决方案是用BeanFactoryLocator,它是一个applicationContext的注册点。我可以告诉对象注册点和MVC层从BeanFactoryLocator中装载这些共用对象。

    首先，我必须修改ObjectRegistry类，像这样，它不在明确装载spring-objectregistry.xml文件：

import org.springframework....BeanFactoryLocator ;
import org.springframework.
    ...ContextSingletonBeanFactoryLocator ;
import org.springframework.
    ...BeanFactoryReference ;

// this was an ApplicationContext before
private final BeanFactoryReference _singletons ;

private ObjectRegistry(){

  // ContextSingletonBeanFactoryLocator loads
  //   contents of beanRefContext.xml

  BeanFactoryLocator bfl =
    ContextSingletonBeanFactoryLocator
      .getInstance() ;

  BeanFactoryReference bf =
    bfl.useBeanFactory( "OBJ_REGISTRY_DEFS" );
                         
  _singletons = bf ;

}

public Object get( final String key ){
  return( _singletons.getFactory().getBean( key ) ) ;
}

    这个代码将ApplicationContext用一个BeanFactoryReference替换，从一个BeanFactoryLocator中取得名字为OBJ_REGISTRY_DEFS的对象。

    接下来，将OBJ_REGISTRY_DEFS对象定义在一个叫beanRefContext.xml的文件中.

<beans>

  <bean
    id="OBJ_REGISTRY_DEFS"
    class="...ClassPathXmlApplicationContext"
  >
    <constructor-arg>
      <list>
        <value>spring-objectregistry.xml</value>
      </list>
    </constructor-arg>
  </bean>
</beans>

    名字为OBJ_REGISTRY_DEFS的bean实际上是一个基于原来的对象注册配置文件spring-objectregistry.xml的ApplicationContext。在BeanFactoryReference上调用getBean()方法仅仅是传递了一个潜在的ApplicationContext。

    那只是照顾了ObjectRegistry自己。为了让web层也能用OBJ_REGISTRY_DEFS，使得对象在web层的配置文件(SpringMVC-config.xml)可见，需要在web.xml中添加一些扩展点。

  <context-param>
     <param-name>
       parentContextKey
     </param-name>
     <param-value>
       OBJ_REGISTRY_DEFS
     </param-value>
  </context-param>

  <context-param>

     <param-name>
       locatorFactorySelector
     </param-name>

     <param-value>
       classpath*:beanRefContext.xml
     </param-value>
  </context-param>

    第一个入口告诉web层的Spring配置，对于找不到的对象，它应该访问名字为OBJ_REGISTRY_DEFS的BeanFactoryReference.第二个告诉框架，装载classpath下的名字为beanRefContext.xml文件。

    现在定义在spring-objectregistry.xml中对象对于web层(在SpringMVC-config.xml)的对象是可见的。意思是说我可以慢慢的淘汰ObjectRegistry，而不是一步就要做出很大的改动。

    难看吗？是。耦合代码？是。当你已经有可自己的单态注册?(Absolutely)时,这是一种将你的应用移植到Spring的方法。现在这个应用从将来的重构中被屏蔽了，这个ObjectRegistry(和明确从ApplicationContext中加载的)的移出将仅仅影响ObjectRegistry的客户段代码。

    然而，有一点警告：Spring的文档中也注明BeanFactoryLocator不是常用的，就像上面那样，它应该被用来移植对象。如果你打算在一个新的应用中用Spring,通过比较，你的设计从一开始应该说明合适的Ioc注入。

(总结) The Round-up

    比较原来的app和它的新版本，我首先发现大小上的不同；我写的代码变少了，调试简单了。而且，让Spring来处理如此多的对象实例化和依赖跟踪意味着随着系统的增长我少了一些烦恼。通过Ioc的注册我的测试也变得简单了－我可以通过修改一个xml文件将一个DAO换成另一个进行测试。

    取的更高层次的见解，我考查了我用过的Spring的特殊的组件。对象查找和JDBC templates很常见。在一个相当大小的工程中，框架处理象查找或数据库链接是共用的。那就是使得Spring如此有用的地方－感觉像是本身就有的。我们以前见过它，只是现在当我们从一个工程移动到另一个对象时，不必要(重写)写它。因为是一个附加的特性，Spring的全体人员能够专注于增强他们的产品，并且我们关心我们自己的。

    采用Spring的另外一个好处是，不是要嘛全有要嘛全无的去努力。能够做到不彼此影响将Spring应用到每个应用层。因此我可以从前面走过的任何点上听下来。例如，我只想要Spring的JDBC模板部分，那我只修改我的DAO，而不触及到我应用的其他部分。
虽然Spring的会议我迟到了，但我还是非常高兴能够参加。

查看本文来源