7

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

框架的架构由产品建立和验证测试。我只想创建一个 .NET 处理器来将人类可读的规则转换为已编译的规则实现。

我知道的选项是：

不幸的是，考虑到 DSL 语法（它会不断发展），这些方法都没有提供任何东西来构建或多或少友好的 IDE 来编辑 DSL。

有什么想法或提示吗？

4

11 回答 11

8

另一个可能有趣的替代方法是使用 F# 引号。

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

不确定商务规则的外观，但您可以编写如下内容：

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

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

DSL 的一个很好的例子是 F# 单元测试框架：

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

  • 如果您使用 Visual Studio 编辑 DSL（并且您可以使用免费安装 F# 的 Shell 版本），您将免费获得非常好的编辑体验。不仅是语法高亮，还有 IntelliSense，它会建议可能的结构，还有一个背景类型检查，作为你的 DSL 的“语法”检查器。
  • 与其他方法相比，这可能是最容易实现的方法之一。
  • 唯一的限制是您受 F# 语法的限制。但是，设计自己的语言确实很困难，所以这可能一点也不坏。尤其是考虑到 F# 的灵活性。

[/编辑]

希望这可以帮助！

于 2009-02-13T14:49:19.410 回答
8

微软下一代应用开发平台，代号Oslo（现 Delve）

使人们更容易以对他们所从事的问题领域有意义的方式写下来

Oslo 似乎由一个名为“Quadrant”的可视化设计工具、一种名为“M”的建模语言和存储规则的“Oslo”存储库（一个 SQL Server 数据库）组成。

因此，如果我没看错的话，您可以在 M 中定义一种建模语言，使用 Quadrant 使用您自己的建模语言定义和编辑您的验证规则，并编写一个使用 Oslo 存储库的应用程序，生成您的业务规则和验证应用程序.NET 的块。

于 2009-02-16T23:42:58.843 回答
7

业务规则的图形语言不是一个好主意。我会避免它 业务规则中有很多 if 检查和循环，它们不能很好地可视化。

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

要获得编辑代码的非凡用户体验，您需要：

  1. 具有良好错误恢复能力的解析器
  2. 进行增量重新编译的能力

良好的错误恢复允许您从语法不完整的结构中有效地确定程序员的意图。这对于实现智能至关重要。

进行增量重新编译的能力使您能够进行有效的后台编译以响应用户编辑。

获得良好错误恢复的最简单方法是手动编写解析器。这样，您可以使用任意数量的前瞻或算法规则来确定在出现语法错误时该怎么做。

当您使用解析器生成器创建解析器时，您在处理语法错误方面失去了很多灵活性。这种灵活性决定了良好的智能体验和糟糕的智能体验。因此，我建议您使用递归下降手工编写它。

实现有效的重新编译要求您能够： 1) 正确地将语义分析分解为多个阶段（对于 C# 之类的东西，这将是：首先构造名称空间和类型符号，然后解析 using 语句，然后解析基类等）。2）构建相位感知依赖图的能力 3）处理依赖图的算法，并根据用户编辑使其部分无效

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

所以，我会从解析器开始，然后在它之上构建智能。

如果您可以避免VS集成，我会的。集成到 VS 需要大量的管道，并且互操作可能会引起头痛。有几家公司出售您连接解析器的 Windows 窗体编辑器控件。这比 VS 更容易集成。

于 2009-02-13T14:03:42.593 回答
3

我会使用 Boo，我认为它是目前最灵活的 DSL 创建工具之一。关于这个主题有一本非常好的书。Ayende和Rodrigo 的博客也是很好的灵感来源。

关于 IDE，你可以扩展SharpDevelop，看看这个。

于 2009-02-13T15:06:59.117 回答
3

将 DSL 的接缝构建为ANTLR的标准工具- 它是一个强大的词法分析器/解析器生成器，具有许多用于编译器输出的目标语言。它具有 C#、Java、C/C++、Python 等的后端（请参阅代码生成目标列表），并允许您轻松地将自定义代码以目标语言注入编译器。

还有一个非常强大的 IDE (ANTLRWorks) 和大量文档。（查看来自 ANTLR 的作者 Terrence Parr 的The Defenitive ANTLR Reference）关于还有谁使用它的参考，请参见Testimonlals页面。

您仍然需要自己完成 IDE 的大部分工作，但考虑到您将从 ANTLR 获得的强大的编译器框架，这应该会容易得多。此处发布的大多数解决方案都应该是这种情况...

我目前正在使用用 ANTLR 编写的编译器将我们自己的 DSL 预处理为 C/C++ 输出，对此我感到非常满意。广告够了，你应该自己试试看：）玩得开心！

于 2009-02-16T16:02:26.857 回答
2

JetBrains元编程系统

您可以为任何新语言定义自定义语言编辑器和其他约束，以便使用这些 DSL 变得非常简单。不熟悉传统编程的领域专家可以使用特定领域的术语轻松地使用他们的领域特定语言在 MPS 中工作。

于 2009-02-16T07:23:55.980 回答
1

我是新手，但OMeta似乎是开发 DSL 的理想工具。周围似乎没有 IDE，但好消息是可以在 OMeta 中编写的“规则”非常易读。（它处理左递归，这非常酷。）

目前至少在 Javascript（对我来说非常令人兴奋）和 Python 中存在 OMeta 实现，也许还有其他实现。至于 C#，Jeff Moser正在开发一个，您可以在他的博客上阅读并在CodePlex上查看。祝你好运。

于 2009-02-16T14:57:21.710 回答
1

Boo + OMeta = Boo.OMeta.Parser

目前解析器正在开发中，但它已经可以用于创建复杂的外部 DSL。OMeta 是一个强大的工具，它使程序员能够轻松地实现词法分析器和解析器。Boo 的可扩展编译器管道架构允许用 Boo.OMeta.Parser 替换标准的 Boo.Parser。它可以用几乎任何一种语法来扩展 Boo 语法。该示例可以在此处找到。

于 2011-05-17T21:15:42.730 回答
1

我的项目meta#正在尝试解决这个问题。

于 2011-12-14T14:19:40.060 回答
0

如果您想创建一个编辑 DSL 的友好 IDE，使 IDE 完全图形化，并编译为 .NET 对象（或使用 IronPython 之类的东西作为胶水语言）。

如果规则足够简单，您可以以图形方式实现整个规则结构。如果规则足够复杂，“人类可读性”就成为一个不可能的目标。

无论哪种方式，如果创建中间代码的一组 .NET 类或 IronPython 对象不够“人类可读”，那么很可能，您需要比语法更防伪的东西。

也就是说，如果您只是想创建一种程序员可以用来创建业务规则的简单语言，请随意使用上述任何一种语言，并使语法足够简单，不需要 Visual Studio 的 IDE。

于 2009-02-13T13:41:16.953 回答
0

Ruby 是一种用于创建 DSL 的出色语言。例如，Rake是一个用 Ruby 编写的构建脚本 DSL。

使用即将推出的IronRuby，可以编写直接调用 C# 代码的脚本。

这是 一些 关于在 Ruby 中编写 DSL 的文章。

于 2009-02-22T14:32:34.047 回答