在为规则引擎创建DSL时使用什么技术？

Question

您建议使用什么技术为.NET的业务规则和验证应用程序块创建DSL ？为什么？

框架的体系结构由生产建立并经过验证.我只想创建一个.NET处理器,将人类可读的规则转换为已编译的Rule实现.

我所知道的选项是:

遗憾的是,考虑到DSL语法(可能会发展),这些方法都没有提供任何构建或多或少友好的用于编辑DSL的IDE.

任何想法或提示？

Answer 1

微软的下一代应用程序开发平台,代号为Oslo

使人们能够更容易地以对他们正在使用的问题域有意义的方式编写内容

奥斯陆似乎包含名为"Quadrant"的可视化设计工具,名为"M"的建模语言,以及存储规则的"Oslo"存储库(SQL Server数据库).

因此,如果我正确读取内容,您可以在M中定义建模语言,使用Quadrant使用您自己的建模语言定义和编辑验证规则,并编写使用Oslo存储库的应用程序,生成业务规则和验证应用程序阻止.NET.

Answer 2

业务规则的图形语言不是一个好主意.我会避免它业务规则有很多,如果检查和循环,它们不能很好地形象化.

使用文本语言来描述业务规则要好得多.

要获得编辑代码的显着用户体验,您需要:

良好的错误恢复允许您从合成不完整的构造中有效地确定程序员意图.这对实施智慧至关重要.

执行增量重新编译的功能使您能够执行高效的后台编译以响应用户编辑.

获得良好错误恢复的最简单方法是手动编写解析器.通过这种方式,您可以使用任何数量的前瞻或算法规则来确定在存在语法错误时要执行的操作.

当您使用解析器生成器来创建解析器时,您在处理语法错误时会失去很大的灵活性.这种灵活性使得良好的整体性和理性之间存在差异.因此,我建议您使用递归下降手动编写.

实现高效的重新编译需要您能够:1)正确地将语义分析分解为阶段(对于类似C#的东西,这将是:首先构造命名空间和类型符号,然后使用语句解析,然后解析基类等).2)构建阶段感知依赖图的能力3)用于处理依赖图的算法,并且响应于用户编辑使其部分无效

对于完全成熟的编程语言,实现重新编译可能会变得非常棘手.在您的情况下,因为您正在描述业务规则,所以对您来说可能更简单(或者如果编译速度足够快,您可能甚至不需要它).

所以,我将从解析器开始,然后在它上面构建intellisence.

如果你可以避免VS集成,我会的.集成到VS需要大量的管道,并且互操作可能会引起头痛.有一些公司销售Windows表单编辑器控件,你可以解析你的解析器.这比VS更容易集成.

Answer 3

另一个可能有趣的替代方案是使用F#引用.

引号允许您将部分程序视为数据,因此您可以获取AST,分析它并将其转换为其他语言或以某种非标准方式执行.加上F#的灵活性,您应该能够表达很多东西,因此您必须开发一个内部F#DSL /组合器库来描述规则,并使用F#语言的翻译/解释器来运行它们.

不确定bussines规则可能是什么样子,但你可以这样写:

let rule = <@
  if (exists customer having validEmail) then success
  else require whatever 
@>

我在博客上写了这个主题的介绍.不幸的是,F#CTP已经发生了一些重大变化,我还没有更新源代码,但它应该让你很好地了解这种方法的可能性和局限性.

DSL的一个很好的例子是F#单元测试framewrok:

[编辑] 只是为了澄清为什么我认为这可能是一个好方法:

如果您使用Visual Studio编辑DSL(并且您可以免费使用安装了F#的Shell版本),您将获得免费的非常好的编辑体验.不仅是语法突出显示,还有IntelliSense,它会建议可能的构造以及用作DSL的'语法'检查器的背景类型检查.
与其他方法相比,这可能是最容易实现的方法之一.
唯一的限制是你受到F#语法的限制.然而,设计自己的语言确实很困难,所以这可能不是那么糟糕.特别是考虑到F#的灵活性.

[/编辑]

希望这可以帮助!