设计规则系统的良好参考/提示？答案

【问题标题】：Good references / tips for designing rule systems?设计规则系统的良好参考/提示？
【发布时间】：2010-09-09 05:02:10
【问题描述】：

我经常需要实现某种用户可编辑的规则系统——要求通常不同，以至于同一个系统不能直接适用，所以我经常遇到同样的问题——我该如何设计一个规则系统，

可维护
恰当地平衡表现力和易用性
很容易扩展（如果/当我得到 (2) 错误时）。

我认为规则系统/DSL 非常有价值，但我对自己正确设计它们的能力感到不自在。

您必须提供哪些参考资料/提示可以帮助简化此操作？
由于我遇到的问题的性质，现有语言通常不适用。（例如，您不要求普通计算机用户学习 Python 才能编写电子邮件过滤器。）类似地，规则语言，例如 JESS，仅适用于部分解决方案，因为需要在规则语言之上构建一些（更简单的）用户界面，以便非程序员可以使用它。这个界面总是涉及删除一些功能，或者使这些功能更难使用，而process 会带来与上述相同的问题。

编辑：为了澄清，问题是关于设计一个规则引擎，我不是在寻找一个预先构建的规则引擎。如果您建议使用规则引擎，请说明它如何解决有关做出良好设计决策的问题。

【问题讨论】：

标签： user-interface filtering dsl rules

【解决方案1】：

我们很幸运：http://msdn.microsoft.com/en-us/library/bb472424.aspx

【讨论】：

【解决方案2】：

要考虑的 Ruby 实现是 Ruleby (http://ruleby.org/wiki/Ruleby)

【讨论】：

【解决方案3】：

我发现的一件事是能够将规则定义为表达式树使得实现变得如此简单。正如您正确提到的，项目之间的需求是如此不同，以至于您每次都必须重新实现。表达式树与访问者模式之类的东西相结合，构成了一个易于扩展的非常（没有双关语）表达性框架。您可以轻松地将一个非常动态的 GUI 放在满足您需求的表达式树的顶部。

希望这听起来不像我在说一切看起来都像我的锤子上的钉子，因为事实并非如此......只是根据我的经验，这已经派上用场不止一次了 :-)

【讨论】：

我不确定我是否理解表达式树的适用性。您是建议将它们作为规则语言解释器的一个方面，还是使用它们来表示每个规则的选项？我有点困惑。

【解决方案4】：

首先，通常不建议让最终用户定义规则。那是因为他们没有开发背景，可以简单地编写进入无限循环或做其他奇怪事情的“代码”。

因此，要么系统必须防止这种行为（从而使其变得更加复杂），要么接受这种可能性，要么禁止最终用户这样做。

如果您正在使用 .NET，那么通过扩展 Boo 编译器来创建自己的 DSL 非常容易（即使用 Rhino.DSL，您可以拥有一个类的简单 DSL）。

【讨论】：

【解决方案5】：

我们有一个由它的供应商提供的这个工具的内部演示： http://www.rulearts.com/rulexpress.php

作为一家公司，我们在规则引擎（例如 Cleverpath Aion）方面拥有丰富的经验，但主要是面向开发人员的工具。这个工具（rulexpress）非常面向商务人士。它不是规则引擎。但它可以输出 xml 中的所有数据（所以基本上是你喜欢的任何格式），这是我们随后会考虑作为真正规则引擎的输入的东西，例如Windows Workflow Foundation（不是更大/更好的规则引擎之一，但仍然如此）。

这个工具本身看起来很不错，一些我在任何面向开发人员的工具中从未见过的东西。

还有一些围绕 WF 构建的规则管理工具，如果这是您选择的规则引擎，请查看 InRule。

在澄清原始问题后编辑：尽管我很久以前就涉足过这个（用 javacc 编写了一点语言），但我现在认为这是一个糟糕的时间投资。我上面的评论是本着同样的精神：采用一个简单的规则引擎，一个简单的（商业）用户界面，使业务用户易于维护，只需花时间将两者结合在一起。

【讨论】：