9.2 DSL工作台

高屋建瓴地说，DSL设计是一种在所处环境的束缚下，尽可能建立最具表现力的API的一种实践活动。对于内部DSL，我们受到宿主语言的限制。对于外部DSL，我们自行设计的语法局限于我们选用的分析器生成器或组合子。无论哪种情况，我们谈论的仍然是文本形式的DSL。不管我们提供给用户什么样的界面，它的呈现形式总是一种基于文本的结构。我们尽可能为用户改善API的表现力，但只要API是用某种语言实现的，用户终究不得不承担语言运行时强加的规则和限制。

近年出现的另一派思路不再把基于文本的DSL开发范式当做一件理所当然的事情。举个例子，假如我是数据分析专家，那么我会希望天气预报系统的计算引擎里内嵌Excel宏。因为对我来说，电子表格才是最符合直觉的计算逻辑表达方式。而在一个单纯以文本为设计手段的DSL世界里，我们绝无可能跳出语言的桎梏，组织起像电子表格、图标引擎这样的高阶结构。

Eclipse Xtext（见第7章）等框架朝着这个方向前进了一小步。它用元模型取代纯文本格式来保存DSL，而元模型可以被投射到Eclipse编辑器。编辑器具备语法高亮、代码补全等功能。这类框架支持的抽象层次越高，就越便于最终用户自己建立、编辑和维护DSL。而协助最终用户建立、编辑和维护DSL的工具，就叫做DSL工作台。

9.2.1 DSL工作台的原理

我们曾经在第7章用Eclipse Xtext（见第9.6节文献[1]）生成了一个专用的DSL工作台。JetBrains Meta-Programming System（MPS）（见第9.6节文献[2]）和Intentional出品的Domain Workbench（见第9.6节文献[3]）也是同类的工具。它们都放弃了单纯基于文本的编程方式，改用AST等高阶结构来作为基本的存储单元。

工作台的使用者不直接编写文本形式的程序，而是通过一种特殊形式的IDE，叫做投射式编辑器（projectional editor）来操作DSL的结构。DSL工作台通常可以和一些工具，如Microsoft Excel无缝集成，使我们能够调动这些工具去设计DSL的语法和语义。我们在Excel里建立的模型作为元数据保存在工作台的仓库里，对应着DSL里的高层次抽象。

如果需要，我们还可以从工作台仓库里保存的元模型生成指定语言的代码。这样的开发方式不正是领域用户的梦想吗？不正是我们原本赋予DSL的价值诉求吗？领域工作台也许将成为领域专家和程序开发者的理想交汇点。图9-4说明了领域工作台对DSL实现的全程支持。

图9-4　DSL工作台为DSL实现的全部生命期提供支持。领域专家打交道的对象是像Microsoft Excel这样的高层次结构。工作台不直接保存程序文本，而是保存元数据。元数据可以被投射到一种智能的编辑器，叫做投射式编辑器上。我们通过这种编辑器来编辑元数据、处理其版本变迁以及其他方面的管理维护。工作台还拥有生成编程语言（如Java）代码的设施

在更高的抽象层次上编程，这是本书反复论述的一个主题，而且已经成为目前存在的几种DSL工作台的原则共识。它们之间的差别主要体现在抽象的表达上。表9-1总结了部分工作台产品在几个方面的差别。

表9-1　DSL工作台产品的特性差异

DSL工作台绝对是一件值得放进包里随时备用的好工具。那么我们就来说说使用DSL工作台有哪些好处。

9.2.2 使用DSL工作台的好处

不同的工作台在不同的方面各有千秋，但所有的DSL工作台都具有以下优点。

• 分离了DSL界面的关注点和DSL实现的关注点。

• 用户可与高层次结构直接互动。这些结构比一般文本型编程语言中所见的结构层次更高。因此，对于没有编程背景的领域用户来说，工作台方式下的DSL开发更有吸引力。

• 为DSL驱动的开发方式全程提供优厚的环境。

• 较容易完成多种DSL的组合。

但从发展阶段来看，DSL工作台还处在婴儿时期。虽然这项技术前景很好，也已经推广了一段时间，但开发商还需要解决好一些问题才能让DSL工作台成为主流。其中最主要的一个问题是“厂商锁定”（vendor lock-in）。DSL工作台有以下几个最为重要的方面：

• 抽象表示的呈现形式；
• 投射式编辑器；
• 代码生成器。

这几个方面全都被锁定到相应的框架上。当我们无法脱离一个特定平台来建模DSL时，顾虑在所难免。这种锁定意味着为了在项目里实现DSL，开发团队又不得不学习一套专门的工具。DSL工作台即使有这样的缺点，也仍然是一种很有吸引力的技术范式，值得我们继续关注它的未来发展。

除了寄望工作台提供完整的DSL开发环境外，我们还寻求加强IDE对DSL开发的工具支持，以改善眼下的状况。