[转]基于模板的代码生成器设计思路
那么这个抽象的工厂对于我们的代码生成器有什么启发意义吗？
首先，让我们先引进几个术语：代码生成工具、生成控制器、模板参数、模板引擎、模板。
我们暂且不给出这些术语的定义。参考工厂的生产模式，我们可以将代码生成描述为，在代码生成工具（对应为工厂）内有好几个生成控制器（对应为流水线），每一个生成控制器利用模板引擎（对应为模具）读取并分析模板（对应为原材料），然后结合模板参数（对应为原材料），最终生成代码文件（对应为产品）。
是不是有些相似性？而上面引入的5个术语就是基于模板的代码生成器的5大要素。全文都围绕着这5大要素展开。
知道了5要素后，我们一个一个来分析他们。
首先是模板参数。我们首先问自己，什么是模板参数？它有哪些形式？
模板参数，顾名思义，它是针对模板而言的，它依赖于模板，它和模板之间有机的结合，会产生丰富多彩的代码文件。可以说，模板和模板参数之间是相互依存的，谁离开了对方都会成为死物，只有当二者结合，才能产生生命力。但是，除开这些空洞的描述，我们能具体的描述什么是模板参数吗？我们能列举并归纳它有那些形式吗？我无法给它一个准确的定义，就像这个世界的代码一样，它似乎有无数种。现在好像进入了死胡同，哪里是突破口呢？
我们为什么要直接去分析它呢，可不可以从另外一个角度来分析、归纳呢？我们都知道，我们工具要实现的目标是生成代码，也就是说，我们的关注焦点是代码，是程序。而以OO的观点而言，程序是什么？它是由对象组成的。所以，可以说，我们工具要实现的目标是生成’对象’。我们都知道，对象包含了属性和行为，我个人觉得还可以扩展一点，对象的展现。既然我们的整个工具都是围绕对象而运作，那么对于模板参数而言，它也离不开这个范围。
最后，我们可以给模板参数下一个定义，模板参数是对象的属性、行为、展现的描述或抽象。接着，我们可以给模板下一个定义，模板是对象实现的描述。
其次是模板引擎，它的作用是什么？有哪些方式？
模板参数、模板引擎和模板3者相互作用的方式，我们可以划分为3种。一种，我称之为push模式，在这种模式下，生成器将获得的模板参数推入(push)到模板中。这种模式的特点是，对象实现的逻辑由模板来描述，生成器仅仅作为一个推动的工具，利用模板引擎将模板参数推入到模板中，最终生成所需要的代码文件。另外一种，我称之为pull模式，在这种模式下，生成器首先将读取(pull)模板的内容，用模板引擎分析它，然后将分析后的模板与模板参数结合，最终生成所需要的代码文件。这种模式的特点时，生成器本身需要包含一定的代码生成业务逻辑。最后一种我称为混合模式(mix)，在这种模式下，生成器首先将模板参数推入模板中获取代码片段，然后根据生成器根据本身的业务逻辑生成代码并输出，在这种模式下，生成器同样也要有一定的代码生成业务逻辑。
所以，我们可以把生成器看成是模板参数、模板引擎和模板之间的联系纽带。通过生成器，我们可以分隔不同的代码生成方式，从而降低耦合度。
最后是工具。对于工具而言，最重要的是可扩展性。它主要表现为：
1． 能够不断的添加、删除、更新生成器。
2． 能够支持以不同的方式获取业务对象。可以是从数据库中、从文本文件中、从Xml文件中。等等方式。
3． 能够支持多种生成方式，可以是按层生成，可以是按对象生成。等等。
对象
也可以称为业务对象。它主要包含属性、行为和展现。对于代码生成工具而言，主要的问题是挖掘对象、获取属性、定义行为、定义展现、对象映射。
挖掘对象
是工具工作的第一步。对于工具而言，对象的挖掘需要高扩展性。初步列一下，有以下几种方式：
1．通过数据库来挖掘对象。（初期支持SqlServer2000和SqlServer2005）
2．通过Xml文件来挖掘对象。
3．自定义对象。
对象映射
举个例子来说，我们现在有一个学籍系统，其中包含了学生对象，它的属性有姓名、性别、年龄等等。学生所拥有的行为有上课、写作业，同时，为了持久化学生对象，我们还会有新建学生、修改学生、删除学生、查询学生的行为。那么这些属性和行为是否都集中放在一个类中呢？
为了使整个应用程序结构良好，我们通常都会划分几个层。假设，我们现在将应用程序划分为实体层、业务逻辑层、数据访问层、展示层。这样一来，学生对象将在各个层上映射为学生实体对象，学生业务逻辑对象，学生数据访问对象。这，我称之为对象映射。
对象属性
对象的属性可以划分为持久化属性、业务属性与展现属性。一个对象的属性可以同时为持久化属性、业务属性和展现属性。
持久化属性：顾名思义，就是最终将会持久化到数据库（或者其他文件）中的属性。这些属性一般通过数据库来获取。
业务属性：为了满足业务逻辑而定义的属性，一般由用户自己定义。
展现属性：用于对象展现时的属性。
对象行为
对象的行为可以划分为持久化行为、业务行为与展现行为。与对象属性划分有区别的是，一个行为只能属于一种类型。
模板参数
模板参数其实是一个由层次对象构成的对象。对象模型如下图所示：
模板参数由工具创建、初始化、填充对象并传递给生成器。然后由生成器自己决定是将模板参数传递给模板引擎，还是在生成器内部进行解析。
模板
是模板文件及内容在应用程序中的映射。由于在框架内允许用户自定义模板引擎。因此，对模板的内容不做任何限制。但是因为系统需要通过模板来找到对应的模板引擎，顾每个模板都唯一指向一个能解析它的模板引擎。这一点通过对模板文件的强制性命名规则来实现：
模板文件的后缀名一定要为.template
模板的文件名的格式为：*.LanguageCode.TemplateEngineeCode
其中LanguageCode表示模板所对应的语言编码。TemplateEngineeCode表示模板引擎编码。这2项中LanguageCode属于可选项而TemplateEngineeCode是必选项。系统解析时，首先将文件名按句号(.)切割。然后从后往前，首先确认截取的TemplateEngineeCode部分是否为已知的模板引擎编码。如果不是，那么匹配过程结束，系统认为整个模板文件名中没有定义LanguageCode和TemplateEngineeCode。如果是，那么系统继续往上搜索匹配。
所有的模板类都必须继承自AbstractTemplate，接口签名如下：
/// <summary>
/// 模板接口
/// </summary>
public abstract class AbstractTemplate{
/// <summary> /// 模板所对应的语言编码
/// </summary> public abstract string LanguageCode{get;} /// <summary> /// 模板引擎编码 /// </summary> public abstract string TemplateEngineeCode{get;} /// <summary> /// 模板内容 /// </summary> public abstract string Content{get;} /// <summary> /// 模板文件路径 /// </summary> public abstract string FilePath{get;} /// <summary> /// 获取一个值，表示该模板是否为有效的 /// </summary> public virtual bool Valid { get { if(this.TemplateEngineeCode.Trim() == string.Empty) return false; else return true; } }}
模板引擎
模板引擎和模板是代码生成的一对基石，它们之间的相互作用从而满足了灵活多变的代码生成需求。模板引擎和模板是相互依赖的，没有了模板，系统无法生成满足需求的代码；没有模板引擎，系统无法解析模板，从而也无从谈起代码生成。
模板引擎的作用是解析模板，将解析后的结果与模板参数结合，最终输出代码或代码片段。模板引擎和模板之间通过模板引擎编码来对应。
Note：模板引擎编码必须在整个系统中唯一。
/// <summary>/// 模板引擎接口/// </summary>public interface ITemplateEnginee{ /// <summary> /// 获得模板引擎的生成模式 /// </summary> EngineMode Mode{get;} /// <summary> /// 模板引擎编码 /// </summary> string EngineCode{get;} /// <summary> /// 推模式 /// </summary> /// <param name="pMobj">映射对象</param> /// <returns>返回生成的代码</returns> string Push(MappingObject pMobj); /// <summary> /// 拉模式 /// </summary> /// <param name="pTemplate">模板</param> /// <returns>返回代码片段列表</returns> CodeSectionList Pull(AbstractTemplate pTemplate); /// <summary> /// 混合模式 /// </summary> /// <param name="pMobj">映射对象</param> /// <returns>返回代码片段列表</returns> CodeSectionList Mix(MappingObject pMobj);} 代码片段
当模板引擎是使用Pull模式或者Mix模式时，引擎返回的将是代码片段。
那么什么是代码片段呢？为了方便用户自己设计、实现模板引擎和对应的模板，代码片段的定义应该模糊一些。我们可以仅仅简单的把它看作是可编译代码的一个片段，它可以是逻辑完整的，比如像字段、属性、方法之类的，也可以是逻辑不完整的，比如是方法的一部分等等。
代码片段由模板引擎生成，由生成器处理，最终形成所需要的代码文件。它对应的类声明如下：
/// <summary>/// 代码片段/// </summary>public class CodeSection{
private fields constructor properties} 生成器
我们可以生成器看成是一个总装工厂，在这里，将把模板参数、模板引擎、模板组合起来，最终生成我们所需要的代码文件。当然，特定的生成器对于模板参数、模板引擎或者模板会有所限制，就例如空客的A300总装工厂只组装A300而不能组装A100等等其他飞机。
生成器生成的方式主要可以分为横向和纵向以及二者的结合。
1． 横向
即代码文件按层来生成。举个例子，系统可以先一次性的生成Entity层的所有类。
2． 纵向
即代码文件按业务对象来生成。举个例子，系统可以生成某个业务对象的Entity层、Dao层、Biz层的类。
3． 混合
即横向和纵向的结合。
4． 全部
生成模板参数中所定义的全部的类（实际是指模板参数中所有Tier下的所有的MappingObject）。
所有的生成器都必须实现IBuilder接口，接口原型如下：
/// <summary>/// 生成器接口/// </summary>public interface IBuilder{ /// <summary> /// 生成方式 /// </summary> BuildMode Mode{get;} /// <summary> /// 模板参数 /// </summary> TemplateParameter Parameter{get;set;} /// <summary> /// 生成器的内置生成条件 /// </summary> BuildCnd InnerBuildCondition{get;} /// <summary> /// 生成代码文件 /// </summary> /// <param name="pCondition">过滤条件</param> void Build(BuildCnd pCondition);} 代码文件
代码文件可以分为类文件、配置文件、组织文件。
类文件就是我们通常所理解的代码文件。配置文件也很好理解，我们都经常会用到，通常都是xml格式的，例如app.config、web.config等等。而组织文件其实就是指组织类文件、配置文件的一些辅助文件。例如使用VS集成编译环境时，由编译环境生成的.sln、.suo、.csproj文件等。
待解决问题
1． 对于模板参数，是否需要抽象出模板参数构造器？
2． 映射对象所对应的模板，是在模板参数中体现，还是在生成器中指定？
自答：
因为现在模板和映射对象之间并无内在的关联关系，因此，在生成器中指定模板参数无法解决
映射对象与模板对应的问题。所以还是应该在模板参数中指定映射对象所使用的模板。但是生
成器可能无法匹配相应的模板（例如支持push模式的生成器无法匹配由pull模式的模板引擎分
析的模板）。
3． 层的定义是由系统来定义，还是由用户自己定义？如果是用户自己定义，如何融入框架内？
自答：
层还是应该由自己定义，这样系统灵活性高。
4． 对象的展现包含哪些内容？是否可以抽象出这个概念？这个概念对代码生成有没有意义？
5． 现在所涉及的代码生成都仅仅考虑的是类文件，配置文件和组织文件是否可以生成？如果可以生成，怎么整合到框架内？
6． 模板参数还是太单薄。
7． 最关键的一点，这个框架是否值得去尝试去实现他？类图
