似乎由名为“Quadrant”的可视化设计工具、名为“M”的建模语言和“奥斯陆”存储库组成（SQL Server 数据库）存储规则。
因此，如果我理解正确，您可以在 M 中定义建模语言，使用 Quadrant 使用您自己的建模语言定义和编辑验证规则，并编写一个利用 Oslo 存储库的应用程序，生成您的业务规则和验证应用程序.NET 的块。
Microsoft's next generation application development platform, codenamed Oslo (now Delve)
Makes it easier for people to write things down in ways that make sense for the problem domain they are working in
Oslo seems to consist of a visual design tool named "Quadrant", a modelling language named "M", and the "Oslo" repository (a SQL Server database) storing the rules.
So if I read things correctly, you could define a modelling language in M, use Quadrant to define and edit your validation rules using your own modelling language, and write an application that makes use of the Oslo repository, generating your Business Rules and Validation Application Block for .NET.
Another possibly interesting alternative is to use F# quotations.
Quotations allow you to treat part of the program as data, so you can get the AST, analyze it and translate it to other language or execute it in some non-standard way. Together with the flexibility of F#, you should be able to express many things, so you'd have to develop an internal F# DSL/combinator library for describing the rules and a translator/interpreter for F# quotations to run them.
Not sure how a bussines rule might look like, but you could write something like this:
let rule = <@
if (exists customer having validEmail) then success
else require whatever
@>
I wrote an introduction to this topic on my blog. Unfortunatelly, there have been some big changes in the F# CTP and I haven't yet updated the source code, but it should give you a good idea of what are the possibilities & limitations of this approach.
[EDIT] Just to clarify why I think this may be a good approach:
If you use Visual Studio for editting the DSLs (and you can use the Shell version with F# installed for free), you'll get a very good editing experience for free. Not only syntax highlighting, but also IntelliSense that'll suggest the possible constructs and also a background type-checking that serves as 'grammar' checker for your DSL.
Compared to other approaches this one is perhaps one of the easiest to implement.
The only limitation is that you're bounded by the F# syntax. However, designing your own language is really difficult, so this may not be that bad at all. Especially given the flexibility of F#.
如果你可以避免 VS 集成，我会的。 集成到 VS 需要大量的管道，并且互操作可能会引起头痛。 有几家公司销售 Windows 窗体编辑器控件，您可以将解析器连接到这些控件。 这比 VS 更容易集成。
A graphical language for business rules is not a good idea. I would avoid it Business rules have lots of if checks and loops in them, which don't visualize well.
You're much better off with a textual language for describing business rules.
To get a phenomenial user experience for editing code you need:
A parser with good error recovery
The ability to do incremental re-compilation
Good error recovery allows you to effectively determine programer intent from syntatically incomplete constructs. That's crucial for implementing intellisence.
The ability to do incremental-recompilation gives you the ability to do efficent background compilation in response to user edits.
The easiest way to get good error recovery is to write your parser by hand. That way you can use whatever amount of look ahead, or algrorithmic rules, for figuring out what to do in the presence of syntax errors.
When you use a parser generator to create your parser, you loose a lot of flexibility in dealing with syntax errors. That flexibility makes the difference between a good intellisence expereince and a crapy one. So, I recommend you just write it by hand using recursive descent.
Implementing efficent re-compilation requires you to be able to : 1) Properly break down semantic analysis into phases (for something like C# this would be: first construct namespace and type symbols, then resolve using statements, then resolve base classes, etc). 2) The ability to construct a phase-aware dependency graph 3) Algorithms for processing the dependency graph, and invalidating parts of it in response to user edits
For full-flegged programing language, implementing re-compilation can get really tricky. In your case, because you are describing business rules, it might be much simpiler for you (or if compilation is quick enough you might not even need it).
So, I would start with the parser, and then build intellisence on top of it.
If you can avoid VS integration, I would. Integrating into VS requires A LOT of plumbing, and the interop is likely to cause headaches. There are a few companies that sell windows forms editor controls that you hook your parser up to. That are much easier to integrate with than VS.
I'd use Boo, I think it's currently one of the most flexible tools for DSL creation. There's a very good book about the subject. Ayende's and Rodrigo's blogs are good inspiration too.
About the IDE, you could extend SharpDevelop, take a look at this.
The standard tool for building DSL's seams to be ANTLR - it is a powerful lexer / parser generator with a lot of target languages for compiler output. It has backends for C#, Java, C/C++, Python etc. (see the code generation targets list) and lets you inject custom code into your compiler in your target language easily.
There is also a very powerful IDE (ANTLRWorks) and lots of documentation. (Check out The Defenitive ANTLR Reference from Terrence Parr, the author of ANTLR) For References on who else uses it see the Testimonlals page.
You still need to do most of the plumbing for the IDE yourself, but it should be much easier given the robust compiler framework you will get from ANTLR. This should be the case for most solutions posted here ...
I'm currently using a compiler written with ANTLR to preprocess our own DSL to C/C++ output and am very happy with it. Enough of the advertisement, you should try it for yourself :) Have fun!
You can define custom language editors and other constraints for any new language, so that working with those DSLs becomes really simple. Domain experts who are not familiar with traditional programming can easily work in MPS with their domain-specific languages using domain-specific terminology.
I'm new to it, but OMeta seems like an ideal tool for developing DSLs. There doesn't seem to be an IDE around it, but the good news is that the "rules" one can write in OMeta are very readable. (And it deals with left-recursion, which is highly cool.)
There are currently OMeta implementations in at least Javascript (very exciting to me) and Python, perhaps others. As for C#, Jeff Moser is working on one, which you can read about on his blog and see over at CodePlex . Good luck.
Currently the parser is under development but it can already be used for creation of complex external DSLs. OMeta is powerful tool which enables programmers to easily implement lexical analyzers and parsers. Extendable compiler pipeline architecture of Boo allows to replace standard Boo.Parser with Boo.OMeta.Parser. It can be used to extend Boo syntax with almost any kind of syntax. The example can be find here.
也就是说，如果您只想创建一种简单的语言供程序员用来创建业务规则，请随意使用上述任何语言，并使语法足够简单，不需要 Visual Studio 的 IDE。
If you want to create a friendly IDE that edits the DSLs, make the IDE fully graphical, and compile to .NET objects (or use something like IronPython as a glue language).
If the rules are simple enough, you can implement the entire rule-structure graphically. If the rules are complex enough, "human readability" becomes an impossible goal.
Either way, if a set of .NET classes or IronPython objects that create the intermediary code isn't "human readable" enough, then chances are, you want something more dummy-proof than a grammar.
That said, if you just want to create a simple language that programmers can use to create Business Rules, feel free to use any of the above, and make the syntax minimalistic enough not to need Visual Studio's IDE.
您可以使用 Prolexy。 Prolexy 是一个规则引擎，目前可用作 SaaS，允许您轻松定义业务对象并使用它提供的规则编辑器轻松定义规则集。 并通过 REST API 执行所需的规则。 它的规则编辑器非常智能，可以向您显示语法和语义错误。
You can use Prolexy. Prolexy is a rules engine that can currently be used as a SaaS and allows you to easily define your business objects and easily define your set of rules using the rules editor that it provides. and execute the desired rules through REST API. Its rules editor is intelligent and can show you syntax and semantic errors.
发布评论
评论（12）
微软下一代应用程序开发平台，代号 奥斯陆（现为 Delve）
似乎由名为“Quadrant”的可视化设计工具、名为“M”的建模语言和“奥斯陆”存储库组成（SQL Server 数据库）存储规则。
因此，如果我理解正确，您可以在 M 中定义建模语言，使用 Quadrant 使用您自己的建模语言定义和编辑验证规则，并编写一个利用 Oslo 存储库的应用程序，生成您的业务规则和验证应用程序.NET 的块。
Microsoft's next generation application development platform, codenamed Oslo (now Delve)
Oslo seems to consist of a visual design tool named "Quadrant", a modelling language named "M", and the "Oslo" repository (a SQL Server database) storing the rules.
So if I read things correctly, you could define a modelling language in M, use Quadrant to define and edit your validation rules using your own modelling language, and write an application that makes use of the Oslo repository, generating your Business Rules and Validation Application Block for .NET.
另一个可能有趣的替代方案是使用 F# 引号。
引用允许您将程序的一部分视为数据，因此您可以获取 AST，对其进行分析并将其翻译为其他语言或以某种非标准方式执行。 加上 F# 的灵活性，您应该能够表达许多内容，因此您必须开发一个内部 F# DSL/组合器库来描述规则，并开发一个 F# 引用的翻译器/解释器来运行它们。
不确定商业规则是什么样子，但你可以写这样的内容：
我在我的博客上写了对此主题的介绍。 不幸的是，F# CTP 发生了一些重大变化，我还没有更新源代码，但它应该让您很好地了解可能性和用途。 这种方法的局限性。
DSL 的一个很好的例子是 F# 单元测试框架：
[编辑]
只是为了澄清为什么我认为这可能是一个好方法：
[/编辑]
希望这有帮助！
Another possibly interesting alternative is to use F# quotations.
Quotations allow you to treat part of the program as data, so you can get the AST, analyze it and translate it to other language or execute it in some non-standard way. Together with the flexibility of F#, you should be able to express many things, so you'd have to develop an internal F# DSL/combinator library for describing the rules and a translator/interpreter for F# quotations to run them.
Not sure how a bussines rule might look like, but you could write something like this:
I wrote an introduction to this topic on my blog. Unfortunatelly, there have been some big changes in the F# CTP and I haven't yet updated the source code, but it should give you a good idea of what are the possibilities & limitations of this approach.
A good example of DSL is F# unit testing framewrok:
[EDIT]
Just to clarify why I think this may be a good approach:
[/EDIT]
Hope this helps!
业务规则的图形语言不是一个好主意。 我会避免它业务规则中有很多 if 检查和循环，这些检查和循环不太直观。
使用文本语言来描述业务规则会更好。
为了获得编辑代码的非凡用户体验，您需要：
良好的错误恢复使您能够从语法不完整的结构中有效地确定程序员的意图。 这对于实现智能至关重要。
进行增量重新编译的能力使您能够进行有效的后台编译以响应用户编辑。
获得良好错误恢复的最简单方法是手动编写解析器。 这样，您就可以使用任意数量的前瞻或算法规则来确定出现语法错误时该怎么做。
当您使用解析器生成器创建解析器时，您在处理语法错误时失去了很多灵活性。 这种灵活性决定了良好的智能体验和蹩脚的智能体验之间的区别。 因此，我建议您使用递归下降手工编写它。
实施高效的重新编译要求您能够：
1) 正确地将语义分析分解为多个阶段（对于像 C# 这样的东西，这将是：首先构造命名空间和类型符号，然后解析 using 语句，然后解析基类等）。
2）构建阶段感知依赖图的能力
3）处理依赖图的算法，并根据用户编辑使部分依赖图无效
对于成熟的编程语言，实现重新编译可能会变得非常棘手。 在您的情况下，因为您正在描述业务规则，所以它对您来说可能要简单得多（或者如果编译足够快，您甚至可能不需要它）。
因此，我将从解析器开始，然后在其之上构建智能。
如果你可以避免 VS 集成，我会的。 集成到 VS 需要大量的管道，并且互操作可能会引起头痛。 有几家公司销售 Windows 窗体编辑器控件，您可以将解析器连接到这些控件。 这比 VS 更容易集成。
A graphical language for business rules is not a good idea. I would avoid it Business rules have lots of if checks and loops in them, which don't visualize well.
You're much better off with a textual language for describing business rules.
To get a phenomenial user experience for editing code you need:
Good error recovery allows you to effectively determine programer intent from syntatically incomplete constructs. That's crucial for implementing intellisence.
The ability to do incremental-recompilation gives you the ability to do efficent background compilation in response to user edits.
The easiest way to get good error recovery is to write your parser by hand. That way you can use whatever amount of look ahead, or algrorithmic rules, for figuring out what to do in the presence of syntax errors.
When you use a parser generator to create your parser, you loose a lot of flexibility in dealing with syntax errors. That flexibility makes the difference between a good intellisence expereince and a crapy one. So, I recommend you just write it by hand using recursive descent.
Implementing efficent re-compilation requires you to be able to :
1) Properly break down semantic analysis into phases (for something like C# this would be: first construct namespace and type symbols, then resolve using statements, then resolve base classes, etc).
2) The ability to construct a phase-aware dependency graph
3) Algorithms for processing the dependency graph, and invalidating parts of it in response to user edits
For full-flegged programing language, implementing re-compilation can get really tricky. In your case, because you are describing business rules, it might be much simpiler for you (or if compilation is quick enough you might not even need it).
So, I would start with the parser, and then build intellisence on top of it.
If you can avoid VS integration, I would. Integrating into VS requires A LOT of plumbing, and the interop is likely to cause headaches. There are a few companies that sell windows forms editor controls that you hook your parser up to. That are much easier to integrate with than VS.
我会使用 Boo，我认为它是目前最灵活的 DSL 创建工具之一。 有一本关于这个主题的非常好的书。 Ayende 和 罗德里戈的博客也是很好的灵感。
关于IDE，你可以扩展SharpDevelop，看看此。
I'd use Boo, I think it's currently one of the most flexible tools for DSL creation. There's a very good book about the subject. Ayende's and Rodrigo's blogs are good inspiration too.
About the IDE, you could extend SharpDevelop, take a look at this.
构建 DSL 接缝的标准工具是 ANTLR - 它是一个强大的词法分析器/解析器生成器，具有很多功能编译器输出的目标语言。 它有 C#、Java、C/C++、Python 等后端（请参阅 代码生成目标列表），让您可以轻松地将自定义代码以目标语言注入到编译器中。
还有一个非常强大的 IDE (ANTLRWorks) 和大量文档。 （查看来自 Terrence Parr 的防御性 ANTLR 参考， ANTLR 的作者）有关其他使用它的人的参考信息，请参阅推荐页面。
您仍然需要自己完成 IDE 的大部分工作，但考虑到您将从 ANTLR 获得的强大的编译器框架，这应该容易得多。 对于此处发布的大多数解决方案来说，情况应该如此……
我目前正在使用用 ANTLR 编写的编译器来预处理我们自己的 DSL 到 C/C++ 的输出，对此我非常满意。 广告已经说够了，您应该亲自尝试一下:)玩得开心！
The standard tool for building DSL's seams to be ANTLR - it is a powerful lexer / parser generator with a lot of target languages for compiler output. It has backends for C#, Java, C/C++, Python etc. (see the code generation targets list) and lets you inject custom code into your compiler in your target language easily.
There is also a very powerful IDE (ANTLRWorks) and lots of documentation. (Check out The Defenitive ANTLR Reference from Terrence Parr, the author of ANTLR) For References on who else uses it see the Testimonlals page.
You still need to do most of the plumbing for the IDE yourself, but it should be much easier given the robust compiler framework you will get from ANTLR. This should be the case for most solutions posted here ...
I'm currently using a compiler written with ANTLR to preprocess our own DSL to C/C++ output and am very happy with it. Enough of the advertisement, you should try it for yourself :) Have fun!
JetBrains 元编程系统
JetBrains Meta Programming System
我是新手，但 OMeta 似乎是一个理想的开发工具DSL。 似乎没有围绕它的 IDE，但好消息是可以在 OMeta 中编写的“规则”非常具有可读性。 （它处理左递归，这非常酷。）
目前至少有 Javascript（对我来说非常令人兴奋）和 Python 以及其他语言中的 OMeta 实现。 至于 C#，Jeff Moser正在开发一项，您可以在 他的博客并查看CodePlex。
祝你好运。
I'm new to it, but OMeta seems like an ideal tool for developing DSLs. There doesn't seem to be an IDE around it, but the good news is that the "rules" one can write in OMeta are very readable. (And it deals with left-recursion, which is highly cool.)
There are currently OMeta implementations in at least Javascript (very exciting to me) and Python, perhaps others. As for C#, Jeff Moser is working on one, which you can read about on his blog and see over at CodePlex .
Good luck.
Boo + OMeta = Boo.OMeta.Parser
目前解析器正在开发中，但它已经可以用于创建复杂的外部 DSL。 OMeta 是一个功能强大的工具，它使程序员能够轻松实现词法分析器和解析器。 Boo 的可扩展编译器管道架构允许用 Boo.OMeta.Parser 替换标准 Boo.Parser。 它可以用来用几乎任何类型的语法来扩展 Boo 语法。
该示例可以在此处找到。
Boo + OMeta = Boo.OMeta.Parser
Currently the parser is under development but it can already be used for creation of complex external DSLs. OMeta is powerful tool which enables programmers to easily implement lexical analyzers and parsers. Extendable compiler pipeline architecture of Boo allows to replace standard Boo.Parser with Boo.OMeta.Parser. It can be used to extend Boo syntax with almost any kind of syntax.
The example can be find here.
我的项目 meta# 正在尝试解决这个问题。
My project meta# is trying to solve this problem.
如果您想创建一个编辑 DSL 的友好 IDE，请使 IDE 完全图形化，并编译为 .NET 对象（或使用 IronPython 等语言作为粘合语言）。
如果规则足够简单，您可以以图形方式实现整个规则结构。
如果规则足够复杂，“人类可读性”就成为一个不可能的目标。
无论哪种方式，如果创建中间代码的一组 .NET 类或 IronPython 对象不够“人类可读”，那么您很可能需要比语法更具有虚拟性的东西。
也就是说，如果您只想创建一种简单的语言供程序员用来创建业务规则，请随意使用上述任何语言，并使语法足够简单，不需要 Visual Studio 的 IDE。
If you want to create a friendly IDE that edits the DSLs, make the IDE fully graphical, and compile to .NET objects (or use something like IronPython as a glue language).
If the rules are simple enough, you can implement the entire rule-structure graphically.
If the rules are complex enough, "human readability" becomes an impossible goal.
Either way, if a set of .NET classes or IronPython objects that create the intermediary code isn't "human readable" enough, then chances are, you want something more dummy-proof than a grammar.
That said, if you just want to create a simple language that programmers can use to create Business Rules, feel free to use any of the above, and make the syntax minimalistic enough not to need Visual Studio's IDE.
Ruby 是创建 DSL 的绝佳语言。 例如，Rake 是一个用 Ruby 编写的构建脚本 DSL。
通过即将推出的 IronRuby，可以编写直接调用 C# 代码的脚本。
这里 一些关于用 Ruby 编写 DSL 的文章 。
Ruby is a great language for creating DSLs. For example Rake is a build script DSL written with Ruby.
With the forthcoming IronRuby it is possible to write scripts that call your C# code directly.
Here's some articles on writing DSLs in Ruby.
您可以使用 Prolexy。 Prolexy 是一个规则引擎，目前可用作 SaaS，允许您轻松定义业务对象并使用它提供的规则编辑器轻松定义规则集。 并通过 REST API 执行所需的规则。 它的规则编辑器非常智能，可以向您显示语法和语义错误。
You can use Prolexy. Prolexy is a rules engine that can currently be used as a SaaS and allows you to easily define your business objects and easily define your set of rules using the rules editor that it provides. and execute the desired rules through REST API. Its rules editor is intelligent and can show you syntax and semantic errors.