DSL 初步的设计和探索 (3)

DSL 是一个好东西,之前几年零零星星的只是探索,虽然也用在了一些项目中,但是总觉得有些不完美。

首先我们定义了一个 DSL 的语言,称之为 r2,r2的解析是通过一个配置文件来定义语法,r2从某种程度上更像一个命令行的定义工具。

然后我们将 r2的解析器和编译器分别定义为 c1和c2,c1是负责解析语法,根据配置文件,配置文件定义了所有参数的名称、允许值类型、允许值范围等;c1会将解析通过的 r2命令生成 json 格式对象,然后 c2会将这个 json 根据业务场景来生成sql 语句或者 html 等。我们目前的应用场景就是 sql 的生成和 html 网站的生成。

r2 作为 dsl 的问题在于:

  • r2的问题在于虽然形式上和一般的命令行没有差别,但是还是需要学习的。
  • r2的配置文件虽然可以定义各类需要的参数和取值范围,很灵活,但是其定义还是有不低的学习曲线。
  • 因为 r2是类似命令行的方式,所以缺乏基本语言的判断、循环、分支等,更不要说面向对象继承等这些了。

c1的问题:

  • 配置文件随着语法表现力的需要的增强,解析复杂度陡然上升。对于 sql 和 html 这样的互相关联性不强的场景还可以应付,但是如果要把 dsl 用在业务逻辑的描述,c1已经显得有点力不从心。

c2的问题:

  • 目前 c2在实现 sql 和 html 的生成时候,用的是基于模板的配置方式,实现上还是比较复杂的,从中间状态 json 到这些最终文件,这里是借用了一些编译的基本原理,问题是 json 描述 key-value 的确不错,但是对于语法的描述就比较弱了。

综上所述,我们继续探索新的 dsl 的实现方式和更广阔的应用场景。

ps

2015年用了半年业余时间,开发了 r2的定义和 r2c1,然后其他同事继续开发了 r2c2等,2017年,同事们将 r2这个 dsl 模式应用到一些业务场景中,这三年,对我们来说,还是走出了艰难的第一步。从2015-2016年中间,还是浪费了一些时间,当时一些同事对于 dsl 整体的理解或许还有所欠缺。所以不管之后怎么继续,先用这些文字来将思想统一。

发表评论

电子邮件地址不会被公开。 必填项已用*标注