我经常需要实施某种用户可编辑的规则系统-要求通常相差甚远，以至于同一系统不能直接适用，因此我经常遇到相同的问题-我如何设计一个可以

• 是可维护的
• 易于兼顾表现力和易用性
• 很容易扩展(如果/当我弄错(2)时)。

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

我们需要提供哪些参考/技巧以帮助简化此过程？
由于我遇到的问题的性质，现有语言通常不适用。 (例如，我们不要求一般计算机用户学习python来编写电子邮件过滤器。)同样，规则语言(例如JESS)仅是部分解决方案，因为需要在某些(更简单)的用户界面上进行构建。 -规则语言的顶部，以便非程序员可以使用它。该界面总是涉及删除某些功能，或者使这些功能更难以使用，并且该过程也产生了上述相同的问题。

编辑：澄清一下，问题是关于设计规则引擎，我不是在寻找预先构建的规则引擎。如果我们建议使用规则引擎，请解释一下规则引擎如何解决有关制定良好设计决策的问题。

解决方案

回答

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

回答

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

回答

我发现的一件事是，能够将规则定义为表达式树，因此实现起来非常简单。正如我们正确提到的，项目之间的需求是如此不同，以至于我们每次都必须重新实现。表达式树与诸如访问者模式之类的东西共同构成了一个非常易于扩展的(无双关语)表达框架。而且，我们可以轻松地在表达式树的顶部放置一个非常动态的GUI，它可以满足需求。

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

回答

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

因此，或者系统必须防止这种行为(从而使其变得更复杂)，或者接受这种可能性，或者不允许最终用户这样做。

如果我们使用的是.NET，则通过扩展Boo编译器来创建自己的DSL极其容易(即使用Rhino.DSL，我们可以使用一类简单的DSL)。

回答

我们由供应商提供了此工具的内部演示：
http://www.rulearts.com/rulexpress.php

作为一家公司，我们在规则引擎(例如Cleverpath Aion)方面拥有丰富的经验，但主要是面向开发人员的工具。该工具(rulexpress)非常面向商务人士。它不是规则引擎。但是它可以将所有数据输出为xml(基本上是我们喜欢的任何格式)，然后我们将其视为真实规则引擎的输入，例如Windows Workflow Foundation(不是更大/更好的规则引擎之一，但仍然是)。

该工具本身看起来还不错，这是我在面向开发人员的工具中从未见过的东西。

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

在澄清原始问题后进行编辑：
尽管我很早以前就涉足了这一领域(用javacc编写一种语言)，但我现在认为这是一个不好的投资。我上面的评论是本着同样的精神：采用一个简单的规则引擎，一个简单的(商业)UI，使业务用户易于维护，并且只花时间将两者捆绑在一起。