问题可能是复合的,让我扩展它:
我们的主要问题是文档和代码之间的差距。我们的产品基于数百个用户定义的规则,我们希望加快变更请求。
如果我们能够为用户提供一个简单的设计器并获取输出,那么在将其转换/编译为C#/ IL代码后,我们就会有一个快速的变更请求周期。
我知道我们的问题是具体的,但任何“墙上的砖头”都是受欢迎的!
示例:
C#类,主题为:
public class TestA
{
public bool B {...}
public bool C {...}
}
在设计师中,我们应该能够创建
DSL中的输出:
If TestA.B AND TestA.C Then Return True;
C#输出:
if (testA.B && testA.C) { return true; }
更新#1
我很高兴使用支持使用静态类型.NET类的DSL语言。我的意思是如果用户可以检查代码(示例中的“DSL中的输出”),我们不需要设计器。
更新#2
基于tipp,我盯着表情树。几天后我遇到了DLinq - 我从来不是DLinq的忠实粉丝,但在这种情况下非常适合问题领域。
答案 0 :(得分:5)
你可以自己建立这样的东西。
您可以使用Type.GetMembers()
获取类的所有公共属性的列表但是,我不会生成C#代码,而是使用表达式树。
这样,当用户更改规则时,您不需要涉及C#编译器。相反,您可以将规则存储在数据库中,在运行时加载它们,然后使用Expression.Compile()方法创建一个可以调用以运行代码的委托。
<强>更新强>
在评论中有人问“Expression Tress和域特定语言有什么区别?”
以下是答案:
表达式树和特定于域的语言是正交的东西。
Expression tress只是一个表示C#表达式的API,可以方便地在运行时动态转换为委托。
DSL或域特定语言是一种旨在解决一小类问题的编程语言。
它们本质上是完全不同的东西。
如果您愿意,可以将表达式树用作DSL实现的一部分。 Linq为此目的使用它们。
但是,在您的情况下,您不需要DSL。您需要的是一个生成规则的用户界面(类似于outlook的工作方式),然后是执行这些规则的方法。
创建UI只是普通的UI开发。
您可以使用表达式树来实现规则。
答案 1 :(得分:0)
一个鲜为人知的事实是,Windows Workflow Foundation的设计者及其规则引擎尤其可以托管在与Visual Studio分开的Windows窗体应用程序中。以这种方式编写的规则可以类似地独立于实际工作流程进行评估。
请参阅WF Scenarios Guidance: Workflow Designer Re-Hosting和Tutorial: Hosting the WF Designer。