您会推荐什么技术来为Business Rules and Validation Application Block for .NET创建DSL？为什么？什么技术用于为规则引擎创建DSL？
框架的体系结构是由生产建立和验证测试的。我只是想创建一个.NET处理器来将人类可读的规则转换为已编译的Rule实现。
，我所知道的选项是：.NET Boo
遗憾的是这些方法都没有提供任何构建或多或少友好的用于编辑DSL的IDE，只要DSL语法（将会发展）。
任何想法或提示？
微软的下一代应用程序开发平台，代号为Oslo
使人们更容易写下来的方式，对问题域，他们在工作的意义
奥斯陆似乎由名为“Quadrant”的可视化设计工具，名为“M”的建模语言和存储规则的“Oslo”存储库（SQL Server数据库）组成。
所以如果我正确地阅读了一些东西，你可以在M中定义一个建模语言，使用Quadrant来使用你自己的建模语言来定义和编辑你的验证规则，然后编写一个利用奥斯陆知识库的应用程序， .NET的规则和验证应用程序块。
如果您想要创建一个友好的IDE来编辑DSL，请使IDE完全图形化，并编译为.NET对象（或使用类似IronPython作为粘合语言）。
如果规则很简单，可以用图形方式实现整个规则结构。 如果规则足够复杂，“人的可读性”就成为不可能的目标。无论采用哪种方式，如果创建中间代码的一组.NET类或IronPython对象足够不够“人类可读”，那么很可能是，您想要的东西比语法更能防伪。这就是说，如果你只是想创建一个程序员可以用来创建业务规则的简单语言，可以随意使用上述任何一种语言，并且使语法足够简单，而不需要Visual Studio的IDE。
业务规则的图形化语言不是一个好主意。我会避免它商业规则有很多如果检查和循环，它们不可视化。
用描述业务规则的文本语言你会好得多。
要获得编辑代码phenomenial的用户体验，您需要：
良好的错误恢复的能力，使您从合成不完整的构建体有效地确定programer意图。这对于实施智慧至关重要。
执行增量重新编译的能力使您能够对用户编辑做出有效的后台编译。
获得良好错误恢复的最简单方法是手动编写解析器。通过这种方式，您可以使用任何数量的预测或algrorithmic规则来确定在出现语法错误时应采取的措施。
当您使用解析器生成器来创建解析器时，您在处理语法错误时失去了很多灵活性。这种灵活性使得良好的智力经验与疗法之间的差异成为可能。所以，我建议你用递归下降手工编写它。 1）正确地将语义分析分解为阶段（对于像C＃这样的东西，这将是：首先构造命名空间和类型符号，然后使用语句解析，然后解析基础课程等）。 2）构建一个相感知依赖图 3）算法用于处理依赖图，并且响应于用户无效的它的部分的能力编辑
对于全flegged编程语言，实施重新编译可以得到真的很棘手。就你而言，因为你正在描述业务规则，所以对你来说可能更简单（或者如果编译足够快，你甚至可能不需要它）。
所以，我会先从解析器开始，然后在它上面构建智能。
如果你能避免VS集成，我会的。整合到VS需要很多管道，互操作可能会导致头痛。有几家公司出售Windows窗体编辑器控件，可以解决您的解析器问题。这比VS更容易集成。
循环并不像向非程序员解释那样难以形成图形。我已经用图形语言编写了一个循环繁琐的代码，它们并没有你声音那么糟糕。例如Envox CDP。 对于非编码器，解决意味着没有语法错误。 – user54650 2009-02-13 14:23:21
另一个可能有趣的选择是使用F＃语句。
引用语言允许您将程序的一部分视为数据，因此您可以获取AST，分析它并将其转换为其他语言或以非标准方式执行。结合F＃的灵活性，您应该能够表达许多事情，因此您必须开发一个用于描述规则的内部F＃DSL /组合器库以及F＃语句的译码器/解释器来运行它们。
不知道一个bussines规则可能看起来怎么样，但是你可以写这样的事情：
let rule = <@
if (exists customer having validEmail) then success
else require whatever
@>
我写了一个介绍，这个话题在我的博客。不幸的是，F＃CTP发生了一些重大变化，我还没有更新源代码，但它应该给你一个很好的想法，这种方法的可能性有哪些限制。
DSL的一个很好的例子是F＃的单元测试framewrok：
[编辑] 只是为了澄清我为什么想S可以是一个好方法：
[/编辑]
希望这有助于！
我会使用Boo，我认为它是目前DSL创建最灵活的工具之一。关于这个问题有一个very good book。 Ayende's和Rodrigo's博客也是很好的启发。
关于IDE，您可以扩展SharpDevelop，看看this。
JetBrains公司Meta Programming System
您可以自定义语言编辑器等方面的限制对于任何新的语言，使这些DSL的工作变得非常简单。不熟悉传统编程的领域专家可以使用领域特定的语言，使用领域特定的术语轻松地在MPS中工作。
我对此很陌生，但OMeta似乎是开发DSL的理想工具。周围似乎没有IDE，但好消息是人们可以在OMeta中编写的“规则”非常易读。 （它处理左递归，这是非常酷。）
目前有至少在Javascript（我非常兴奋）和Python，也许其他人的OMeta实现。至于C＃，Jeff Moser正在编写一个，您可以在his blog上阅读，并在CodePlex处查看。 祝你好运。
构建DSL接缝的标准工具是ANTLR - 它是一个功能强大的词法分析器/分析器生成器，它具有许多用于编译器输出的目标语言。它具有C＃，Java，C/C++，Python等后端（请参阅code generation targets列表），并允许您轻松地将自定义代码注入目标语言的编译器。
还有一个非常强大的IDE（ANTLRWorks）和大量的文档。 （请查阅Terrence Parr的The Defenitive ANTLR Reference，ANTLR的作者）有关谁还用它的参考资料，请参阅Testimonlals页面。
您仍然需要自己完成IDE的大部分工作，但考虑到您将从ANTLR获得稳健的编译器框架，它应该会容易得多。这应该是这里发布的大多数解决方案的情况...
我目前正在使用与ANTLR编写的编译器预处理我们自己的DSL到C/C++输出，我非常满意。足够的广告，你应该为自己尝试:)玩得开心！
嘘+ OMeta = Boo.OMeta.Parser
目前解析器正在开发中，但它已经可以用于创建复杂的外部DSL。 OMeta是一个功能强大的工具，它使程序员能够轻松实现词法分析器和解析器。 Boo的可扩展编译器管道结构允许用Boo.OMeta.Parser替换标准的Boo.Parser。它可以用于以几乎任何类型的语法扩展Boo语法。 示例可以找到here。
我的项目meta#正试图解决这个问题。
a“to”too much in the topic？ – Svish 2009-02-16 07:30:22
谢谢，错过了那一个。 – 2009-02-16 14:07:12