设计模式综和实战项目x-gen系列二

1 详细功能

1.1 详细功能

配置管理模块的主要功能是：

1：获取用户配置的数据，配置的方式很多，要求除了框架自身提供的配置方式外，还要能支持用户自定义的配置方式。比如：框架本身提供默认的配置方式为xml配置，如果用户想使用数据库来配置，那么框架必须能够支持用户自定义一种数据库配置的方式

2：缓存用户配置的数据，同一份配置数据，在运行期间会多次使用，但是获取用户配置数据的动作就只需要一次就可以了，获取过后，就缓存下来。

3：对外提供接口，让其他模块通过这些接口来获取他们需要的数据

1.2 功能边界

配置管理模块的主要功能就是获取用户配置的数据，然后保管好这些数据，并提供这些数据让模块外部访问。

配置管理模块不关心被访问的数据是怎么来的，它只是按照访问方式去获取这些数据，当然不同的数据格式有不同的访问方式。

虽然需要支持自定义配置方式，但是需要配置的数据是一定的，只是配置的格式不同，访问这些配置数据的方式不同，但最后殊途同归，都想配置管理模块提供相应的数据。因此这个需要配置的数据项是要统一起来的。

配置管理模块不关心获取到的数据是什么，也不关心这些数据的含义，更不关心这些数据怎么用，它只是负责获取这些数据并保存起来。

配置管理模块不关心谁来使用这些数据，也不关心外部获取这些数据后如何使用，它只是负责提供这些数据而已

2 模块对外接口

2.1 对外数据接口设计

目前设计的配置分成三类，虽然配置的方式不固定，但是对于核心框架而言，有一些数据是必需要配置的，所以还是需要设计对外的数据接口。

为了简单，这里以xml为例子来说明定义的数据结构。但是请注意，x-gen框架并不局限于使用xml作为配置的方式，同样你可以选用properties文件、数据库等其他的配置方式。

虽然配置方式不同，需要配置的数据却是一样的，所以，你可以把这里xml描述的配置数据改成任何你希望使用的配置方式相对应的数据结构。

第一类是核心框架运行需要的数据

以xml配置为例，默认取名为GenConf.xml，在每次使用的时候根据需要修改或配置其内容。当然，为了示例简单，就不去做dtd或者schema了。具体示例如下：

<?xml version="1.0" encoding="UTF-8"?>
<GenConf>
<NeedGens>
<NeedGen id="UserGenConf" provider="XmlModuleGenConf" themeId="simple">
<Params>
<Param id="fileName">UserGenConf.xml</Param>
</Params>
</NeedGen>
</NeedGens>
<Themes>
<Theme id="simple">cn/javass/themes/simple</Theme>
</Themes>
<Constants>
<Constant id="prePackage" value="cn.javass"></Constant>
<Constant id="projectName" value="framework"></Constant>
</Constants>
</GenConf>
节点说明如下：
（1）<GenConf>是根节点
（2）<NeedGens> ：用来注册需要generate的模块的配置，里面可以注册很多个需要generate的模块
（3）<NeedGen> ：需要generate的一个模块，属性含义如下：
Ø Id：需要generate的模块的标识名称或编号，必须唯一

Ø provider：用来获取该模块配置数据的程序的标识，该标识对应的实现类定义，在该模块使用的theme里面配置

Ø themeId：该模块生成的时候具体使用的theme的标识

（4）<Params>：参数，通常是根据不同的provider，提供不同的参数配置，每个参数配置都包括参数标识和具体的参数值
（5）<Param>：具体一个参数的配置，值就是参数的值，属性如下：
Ø Id：参数的标识名称或编号，必须唯一

（6）<Themes>：用来注册generate所需要的外部theme，可以配置多个<Theme>
（7）<Theme>：具体的描述一个theme，theme存放的具体位置，可以配置一个相对路径，配置到theme存放的根文件夹即可，属性如下：
Ø Id：theme的标识名称或编号，必须唯一

（8）<Constants>：常量定义，可以配置多个常量
（9）<Constant>：单个常量定义，值就是常量的值，属性为：
Ø id ：常量的标识名称或编号，必须唯一

第二类是用户需要生成的模块的配置数据

比如：用户想要生成一个模块内的增删改查的源代码，里面有每个具体功能的配置，而每个具体功能就是一个源代码文件。

这个也需要在每次使用的时候根据需要来配置，并注册到核心框架运行配置里面去，每次生成主要配置的就是这类数据。

示例如下：
<?xml version="1.0" encoding="UTF-8"?>
<ModuleGenConf>
<ModuleName>UserConf</ModuleName>
<NeedGenTypes>
<NeedGenType id="GenBusinessEbi">
<NeedGenOutType id="File"></NeedGenOutType>
<NeedGenOutType id="My"></NeedGenOutType>
</NeedGenType>
</NeedGenTypes>
<ExtendConfs>
<ExtendConf id="moduleName" isSingle="true">user</ExtendConf>
</ExtendConfs>
</ModuleGenConf>
（1）<ModuleGenConf>：每个模块配置的根节点
（2）<ModuleName>：模块的标识名称，在GenConf的NeedGen里面配置的id就是这个值
（3）<NeedGenTypes>：用来配置需要生成的功能，可以配置多个
（4）<NeedGenType>：配置一个本模块需要生成的功能，属性如下：
Ø id：需要生成的功能的标识，这个标识在theme的配置中定义

（5）<NeedGenOutType>：配置模块的某个功能生成完成后，输出的类型，一个功能可以有多种输出。属性如下：
Ø id：具体输出的标识，这个标识在theme的配置中定义

（6）<ExtendsConfs>：本模块需要配置的，自行扩展的数据，可以配置多个数据。
（7）<ExtendConf>：描述一条自行扩展的数据，属性如下：
Ø id：自定义数据的标识

Ø isSingle：数据是单个值还是一个数组，true表示是单个值，false表示是数组，如果是数组的话，多个值之间用逗号分开

第三类就是外部主题的配置数据

在制作主题的时候就配置好，里面有这套主题需要的外部数据，和预定义好的功能配置，在每次使用的时候一般不需要配置或修改。比如：缺省为xml配置，取名为ThemeConf.xml。

外部主题目前不支持自定义，也就是采用默认的xml方式，而且文件名称也固定是ThemeConf.xml，其实要实现支持自定义也很简单，只是没有必要，那样会无谓的增加复杂度。示例如下：

<Theme id="simple">
<GenTypes>
<GenType id="GenBusinessEbi" type="cn.javass.themes.simple.actions.GenBusinessEbiAction">
<Params>
<Param id="relativePath">business.ebi</Param>
<Param id="mbPathFile">business/Ebi.txt</Param>
<Param id="preGenFileName"></Param>
<Param id="afterGenFileName">Ebi.java</Param>
</Params>
</GenType>
</GenTypes>
<GenOutTypes>
<GenOutType id="Console" type="cn.javass.xgen.output.types.OutputToConsole"></GenOutType>
<GenOutType id="File" type="cn.javass.xgen.output.types.OutputToFile"></GenOutType>
</GenOutTypes>
<Providers>
<Provider id="XmlModuleGenConf" type="cn.javass.xgen.genconf.implementors.xmlimpl.ModuleGenConfXmlImpl"></Provider>
</Providers>
</Theme>
（1）<Theme>：主题配置的根节点，属性如下：
Ø id：主题的标识，必须唯一，在GenConf注册theme的id就是这个值

（2）<GenTypes>：主题提供的可输出的功能，可配置多个
（3）<GenType>：描述一个主题可输出的具体功能，属性如下：
Ø id：功能的标识，必须唯一，在ModuleGenConf里面配置每个模块的NeedGenType的id就是这个值

Ø type：真正实现输出功能的类

（4）Params：配置每个输出类需要的参数，下面可以配置多个param
（5）param：具体的每个参数的配置，值就是参数的值，属性为：
Ø id：参数的标识，在一个params必须唯一

（6）GenOutTypes：主题提供的输出类型，可以配置多个
（7）GenOutType：一个具体的输出类型，属性如下：
Ø id：功能的标识，必须唯一，在ModuleGenConf里面配置每个模块的NeedGenOutType的id就是这个值

Ø type：真正实现输出类型的类

（8）Providers：主题提供的读取配置文件的类型，可以配置多个
（9）Provider：一个具体的读取配置文件的类型，属性如下：
Ø id：功能的标识，必须唯一，在GenConf里面配置NeedGen的provider就是这个值

Ø type：真正实现具体的读取配置文件的类

2.2 对外程序接口设计
为了让外部 获取配置管理模块内的数据，提供相应的API（应用程序接口），也就是GenConfEbi，基本定义如下：

/**

• 对外提供的访问配置数据的API
• @author cc
• @version 1.0
  */
  public interface GenConfEbi {
  /**
• 获取核心框架运行需要的配置数据
• @return 核心框架的配置数据model
  */
  public GenConfModel getGenConf();
  /**
• 获取需要生成的模块配置
• @return 包含需要生成的模块配置数据的Map：key-模块名称,value-相应模块的配置数据Model
  */
  public Map<String, ModuleConfModel> getMapModuleConf();

下面的这些为实现中需要的一些快速获取配置数据的方法//

/**

• 根据需要生成的模块配置和theme中的生成类型编号，来获取相应的theme的生成类型的数据Model
• @param moduleConf 需要生成的模块配置数据Model
• @param genTypeId theme中的生成类型编号
• @return 相应的theme的生成类型的数据Model
  */
  public GenTypeModel getThemeGenType(ModuleConfModel moduleConf,String genTypeId);
  /**
• 根据需要生成的模块配置和theme中的输出类型编号，来获取相应的theme的输出类型的实现类的配置数据
• @param moduleConf 需要生成的模块配置数据Model
• @param genOutTypeId theme中的输出类型编号
• @return 相应的theme的输出类型的实现类的配置数据
  */
  public String getThemeGenOutType(ModuleConfModel moduleConf,String genOutTypeId);
  /**
• 根据需要生成的模块配置和模块配置中的扩展数据编号来获取相应的扩展数据
• @param moduleConf 需要生成的模块配置数据Model
• @param extendId 扩展数据编号
• @return 相应的扩展数据的值
  */
  public ExtendConfModel getModuleExtend(ModuleConfModel moduleConf,String extendId);
  }

有些朋友可能会问，你怎么能定义出这些方法来，很简单，因为我已经把系统整体设计过一遍了，可以知道，外部模块对配置管理的接口基本要求如上。

本文由微信公众号——架构设计一起学推出，
点击“阅读原文”，了解更多！

转载于:https://blog.51cto.com/14152198/2339941