高老庄

先谈下这个解决方案的背景:
    假设一个公司的产品遵循的是先有基础平台,然后在此平台上构建不同的产品,最后每一个产品被实施到特定的项目,那么，他们就构成了一种层次化的结构.每一个层次,需要覆盖一些上一层次的配置或者创建新的配置,如何分割层次间的影响从而保证层次间的独立性，是一个挑战.
    任意层次,可能有多个模块或者组件构成，不同的组件间，配置的类型可能一样，但是配置的数据不一样,那么,如果在配置某个模块时，不比考虑其他模块的配置情况，那么这个模块就拥有开发时的独立性,当组件被集成到同一层次部署运行时，配置的合并和重组是一个问题,并且，组件间可能存在依赖关系,这种依赖关系同时产生了依赖组件间配置加载的优先级问题.
    成熟的软件，一般不会直接将第三方的软件集成，而是将其封装后在纳入进来,第三方组件的配置往往不具备配置的层次化或者模块独立性.在设计第三方组件的集成策略时，需要考虑使其拥有上述两种能力.
    解决上述问题，方式有很多种,我们谈论比较容易实现的一种.
    这种解决方案的基本思路如下:
    首先，设计一个特定的扩展名称的配置文件(模块配置索引文件,MCIF,xml格式)，此配置文件面向的是组件级别，即每个组件定义自己的MCIF.MCIF中定义若干配置类别,即名称空间,每一个名称空间负责完成一类配置，一般,一个名称空间对应一个配置获取接口.这个名称空间中仅仅配置所关注的配置的文件的相对位置(相对此MCIF),这样，最大化的减少了不同配置文件格式对MCIF的影响.
    每一个MCIF的根元素拥有一个parent属性,指向了上一层次,同一层次的MCIF的parent属性都相同.通过parent属性，配置的层次化就不是问题了.
    MCIF有两个特殊的名称空间:
    1.register 定义了所支持的名称空间及其对应的配置解析器,这样,此配置框架就可以允许对名称空间进行扩展.
    2.depends 定义了同一层次的模块间的依赖关系,这个是可选的，如果没有实现或者配置，同一层次的module即为平行的.
    
    当系统启动时,扫描所有的MCIF,并根据parent属性解析出一个层次关系,对每一个层次下module,参考相应的depends设置定义出一个依赖关系.
    当请求某特定的配置时,根据上述的两个关系完成配置的组合，并返回给使用者.
    
    公司最近的重构中，基于这个思想开发的配置小框架，很好完成了多层次，多组件的配置覆盖问题,配置相对以前更清晰、简单，配置过程中的关注点大大减少.