MDSF：代码生成 VS 模型解释

　　在代码生成（Code Generation）介绍中说到模型可以通过代码生成技术和模型解释两种方法在领域框架运行，本篇主要介绍一下这两种方法的利弊。

示例

• 对于UI界面，我们基于模型驱动开发可以采用代码生成和模型解释来生成运行程序。

1. 代码生成：通过模型，直接生成窗体类，生成的窗体类与传统手工写的代码类似
2. 模型解释：在OpenExpressApp中采用的AutoUI是采用模型解释方法，我们通过给系统预定义一些窗体模板，每类模板对应一个窗体模板类，具体窗体由模板读取模型元数据来自动生成界面。刚发现有一个UI自动生成的项Metawidget，它使用的就是模型解释，有时间好好看看。

• 对于实体类的设计：

1. 代码生成：生成具体类
2. 模型解释：解释器生成一个Entity，Name为实体类名称；这个Entity示例下添加多个属性，属性名为实体属性名

代码生成相对于模型解释的好处

• 保护你的知识产权：在产品线工程应用中，使用代码生成只需要给特定用户生成后的代码，而使用模型解释时，你需要把完整的解释引擎以及模型都给客户。
• 适用于客户架构：模型解释必须实现一个特定于自己架构的解释器，而代码生成可以依据客户指导来生成客户需要的代码
• 生成后的实现代码更容易理解：可以通过直接查看生成后的代码来了解应用程序的行为，而采用模型解释需要明白解释器的通用实现以及模型的语义表达
• 容易开始：如果你已经应用过传统方法构建过一个应用程序，那么可以容易的使用代码生成技术把现在的代码转为模板或者替代部分代码。如果你构建了多个相同领域的应用程序，则可以通过分析这些系统的差异，可以把共性问题通过静态代码放在领域框架中，可变代码通过代码生成技术来生成。
• 更容易迭代：上面指出代码生成可以把现有代码使用代码生成技术来生成，我们可以方便的先生成一部分代码，之后再扩展生成其他代码
• 方便利用编译器来进行代码检查：生成代码可以通过编译器来检查代码错误，而模型解释必须自己写一个模型检查器
• 调试生成代码比调试解释器更为容易：但是作为用户，并不太需要调试解释器
• 更容易跟踪模板的更改： 代码生成模板是文本文件，所以通过一些版本控制软件可以很好的进行跟踪，而模型解释代码由于通用性，它的改变会比模板更改跟踪复杂些。

模型解释相对于代码生成的好处

• 适应更快的变化：模型改变不需要额外的重新生成、构建、测试和部署过程，这能明显的缩短总体时间。
• 支持运行期变化：可以通过运行期更改模型来更改应用，而不需要关闭应用程序。
• 更容易部署和运行：代码生成需要使用语言平台进行编译生成目标应用，而使用模型解释不再需要代码，只需要把模型放入模型解释器中即可，因此它可以更容易的让领域专家部署和运行应用，而不只是建模而已。
• 容易更新：很容易更改解释器并重新运行同一个模型，不需要使用更新的生成器再次生成代码。
• 比代码生成更灵活：基于代码生成的模板会有一些限制，而模型解释器可以更灵活的处理。
• 运行期调试模型：模型可以在运行时进行调试，例如像系统工作流一样可以在某个活动中设置断点，这在复杂流程和状态模型中很有用。

采用哪种方法

　　从上面描述来看，代码生成和模型解释两种模型到应用的转换方法各有利弊，并没有一种决定性的论断来告诉你应该选择哪一种方法，这个可能每个人的经验、喜好、以及问题领域都有关系。

　　如果业务复杂，我希望在应用中有相应的类库，这样可以使用OO来编写业务代码，所以我个人偏向于类库生成使用代码生成技术。而界面生成相对来说具有一定的通用性，所以可以使用通用语言在领域框架中建立一些UI模板，通过模型解释来自动生成代码，这也是OpenExpressApp现在的解决方法。

　　如果你也关注MDD，了解代码生成和模型解释，你有什么想法呢？

参考

Model Driven Development: Code Generation or Model Interpretation?

Model interpretation vs. code generation? Both.

Executable models vs code-generation vs model interpretation

代码生成（Code Generation）介绍

 

欢迎转载，转载请注明：转载自周金根 [ http://zhoujg.cnblogs.com/ ]