3-Spring的分模块开发(Context的分级机制)

spring 分模块开发

使用不同的两个 context.xml 配置文件new出来的Context就是不同的Context他们之间不可以进行Bean的互访.只能访问相同的父级Context.

背景
      我们一般采用spring+Struts +ibatis的开发模式，使用spring统管业务bean，当项目很大时， 面临一个bean命名冲突问题，如果和struts一样，采取分模块的方式，不同的模块有自己的命名空间，将会避免几个并行开发的子 系统 或模块共用一套bean配置文件时id产生重名的问题。

简单方案
     整个系统所使用的公共bean，例如数据源、事务管理、iBatis或Hibernate 的引擎、国际化资源文件等，放在一个root context文件中， 构造一个 根ApplicationContext实例，作为各子模块的父,这里就看出Spring 设计 上的易扩展性了，ApplicationContext的构造子允许通过一个父实例来创建。
   
    核心类 ContextHelper ,作为管理器类，如下：
    
 public class ContextHelper {

    // 不同的环境有不同的配置文件


    private static Map _contexts ; //环境容器
    private static ApplicationContext _rootContext; //根环境
    private static final String ROOT_CONTEXT = "conf/rootContext.XML"; //根环境的配置文件
 
   static {
      _contexts = new HashMap();
      try{
        _rootContext = new ClassPathXmlApplicationContext(ROOT_CONTEXT); //创建根环境
      } catch (Exception e) {
        throw new ContextException(e);
      }
   }

  //获取一个Bean, 第一个参数为环境名 另一个参数为Bean名
  public static synchronized Object getBean(String configName, String beanName) {
      ApplicationContext context = getApplicationContext(configName);
      Object bean = context.getBean(beanName);
      return bean;
   }
  

    //lazyload 根据context名从Map中获取一个context
   private static synchronized ApplicationContext getApplicationContext(String  configName) {
     if(_contexts.containsKey(configName)) {
       return (ApplicationContext) _contexts.get(configName);
     }

     //这里规定了模块配置文件的命名规则
     String moduleConfigFile = "conf/" + configName + ".bean.xml";  //规则
     String [] configs = { moduleConfigFile};

     //传入一个配置文件和根Context

      ApplicationContext context = new ClassPathXmlApplicationContext(configs,_rootContext); //创建子Context
     _contexts.put(configName, context);

     return context;
   }
 
   //消息资源文件管理

  public static String getMessage(String key,Object[] arg,Locale l){
    return _rootContext.getMessage(key,arg,l);
  } 
}

   需要注意的一点是，各子模块bean配置文件中，如果引用根配置中的bean，不可以使用local属性了，请使用bean=“dataSource“，一开始没注意到这个问题，总报错，无法正确合并，我调试了好久才发现。

ToDo

  上述方案还比较简陋，主要的隐患在于，各模块之间的通信问题，当前的设计比较适用于各模块耦合度较小的情况，如果有一些bean，供几个模块之间共用，势必也需要提至rootContext.xml中配置，大大增加了根文件的复杂性。
  另外，可供改进处还有一个，每个模块应该允许采用多个bean配置文件，允许将dao、service等tier分开来处理，可以通过建立一个 properties文件，将模块逻辑名与若干配置文件建立映射关系来解决。我得承认，当前的简版方案在context load上有一些hard code的坏气味。