基于模板的代码生成器设计思路

  在讨论代码生成器之前，首先，让我们抛开这个主题，来看看一家工厂。在这家工厂里，有一个很大的厂房，厂房里有好几条生成线在运作，人来人往，川流不息又井井有然。一些工人在搬运各种各样的原材料；一些工人在调试和安装模具；一些工人在流水线上完成各自的工序；一些工人在将成品入库。当然，这可能不是一家现实的工厂，现实的工厂会比这个复杂多，这只是工厂的抽象与简化。

         那么这个抽象的工厂对于我们的代码生成器有什么启发意义吗？

         首先，让我们先引进几个术语：代码生成工具、生成控制器、模板参数、模板引擎、模板。

         我们暂且不给出这些术语的定义。参考工厂的生产模式，我们可以将代码生成描述为，在代码生成工具（对应为工厂）内有好几个生成控制器（对应为流水线），每一个生成控制器利用模板引擎（对应为模具）读取并分析模板（对应为原材料），然后结合模板参数（对应为原材料），最终生成代码文件（对应为产品）。

         是不是有些相似性？而上面引入的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;}