可以从模型生成或配置应用程序的部件。
模型比代码更直接地表示要求。 通过直接从模型派生应用程序的行为，可以比更新代码更快地可靠地响应已更改的要求。 尽管建立派生需要一些初始化工作，但如果预期需求发生变化，或者你计划制作产品的多个变体，这一投入将得到回报。
从模型生成应用程序代码
生成代码的最简单方法是使用文本模板。 可以在保留模型的同一 Visual Studio 解决方案中生成代码。 有关详细信息，请参见:
-
此方法易于以增量方式应用。 从一个仅适用于特定情况的应用程序开始，然后选择其中的一些部分以便与模型有所不同。 重命名这些部件的源文件，使其成为文本模板 （.tt） 文件。 此时，源.cs文件将从模板文件自动生成，因此应用程序将像以前一样工作。
然后，你可以获取代码的一部分，并将其替换为文本模板表达式，该表达式读取模型并生成源文件的该部分。 模型至少有一个值应生成原始源，以便再次运行应用程序，并且它将像以前一样工作。 测试不同的模型值后，可以继续在代码的另一部分插入模板表达式。
这种增量方法意味着代码生成通常是一种低风险方法。 生成的应用程序通常在性能上几乎可以与手写版本媲美。
但是，如果从现有应用程序开始，你可能会发现需要大量重构来分隔受模型管理的不同行为，以便它们可以独立变化。 建议在估算项目成本时评估应用程序的这一方面。
从模型配置应用程序
如果要在运行时改变应用程序的行为，则不能使用代码生成，这会在编译应用程序之前生成源代码。 相反，可以设计应用程序来读取模型，并相应地改变其行为。 有关详细信息，请参见:
-
此方法也可以以增量方式应用，但一开始还有更多工作。 你需要编写将读取模型的代码，并设置一个框架，允许其值可供变量部件访问。 使变量部件泛型比生成代码更昂贵。
泛型应用程序的性能通常低于其特定对应项。 如果性能至关重要，项目计划应包括对此风险的评估。
开发派生应用程序
你可能会发现以下一般准则很有用。
从具体开始，再到一般。 首先编写应用程序的特定版本。 此版本应在一组条件下工作。 如果对它正常工作感到满意，可以使其中的一些派生自模型。 逐步扩展派生部分。
例如，在设计显示模型中定义的页面的 Web 应用程序之前，请设计具有一组特定网页的网站。
为各种变化的方面建模。 确定哪些方面会变化，无论是在不同部署之间，还是随着需求变化而改变。 应从模型中提取这些方面。
例如，如果网页集和链接之间的链接更改，但页面的样式和格式始终相同，则模型应描述链接，但不必描述页面的格式。
单独的关注点。 如果变量方面可以划分为独立区域，请为每个区域使用单独的模型。 使用 ModelBus，可以定义影响两个模型的操作，以及它们之间的约束。
例如，使用一个模型定义网页和另一个模型之间的导航，以定义页面的布局。
对要求建模，而不是解决方案。 设计模型，使其描述用户要求。 相比之下，不要根据实现的可变方面设计表示法。
例如，Web 导航模型应表示网页和它们之间的超链接。 Web 导航模型不应表示应用程序中 HTML 或类的片段。
生成或解释？ 如果特定部署的要求很少更改，请从模型生成程序代码。 如果要求可能会频繁更改，或者可能存在于同一部署中的多个变体中，请编写应用程序，以便它可以读取和解释模型。
例如，如果使用网站模型开发一系列不同且单独安装的网站，则应从模型生成网站代码。 如果您使用模型来控制每天都会更改的网站，那么最好编写一个 Web 服务器来读取模型并据此呈现网站。
UML 还是 DSL？ 请考虑利用构造型扩展 UML 来创建您的建模表示法。 如果没有符合目的的 UML 关系图，请定义 DSL。 但避免破坏 UML 的标准语义。
例如，UML 类图是框和箭头的集合;通过此表示法，可以理论上定义任何内容。 我们不建议使用类图，除了在描述一组类型的情况下。 例如，可以调整类图来描述不同类型的网页。