.NET 规则引擎
我们的业务要求是让高级用户编辑保险费率和投保规则。我们需要一个网络用户界面，让他们说“这个产品只适合 55 岁以下的人，除非他们来自德克萨斯州并拥有一只贵宾犬”或其他什么。编辑澄清：保险是疯狂的。规则因产品、状态而异，并且不断变化。
我们研究了几个规则引擎，但商业规则引擎有 100K+，而开源规则引擎似乎还没有完成。如果我们提前创建规则，Windows 工作流就可以工作，但在运行时构建它们似乎需要绕过代码访问安全性。太可怕了。
我们疯狂地重新发明这个轮子吗？ .net 有更好的替代方案吗？
We have a business requirement to let power users edit rules for insurance rates and enrollments. We need a web ui that lets them say "this product is only for people <55 unless they are from Texas and own a poodle" or whatever. Edit for clarification: Insurance is insane. The rules differ from product to product, state to state and change constantly.
We looked at a couple of rules engines but the commercial ones are 100K+ and the open source ones don't seem um, finished. Windows Workflow works if we create the rules ahead of time, but building them at runtime seems to require bypassing code access security. That's scary.
Are we nuts to reinvent this wheel? Is there a better alternative for .net?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我不认为规则的评估会成为挑战。我认为更大的挑战是解析用户可以输入的规则。为了解析规则，您应该考虑创建一些 DSL。 Martin Fowler 在此处对此有一些想法。那么也许 ANTLR 可能值得一看。
对于评估部分：我在金融行业工作，规则也很复杂，但我从来没有使用过规则引擎。命令式编程语言（在我的例子中是 C#）的手段（到目前为止）已经足够了。在某些情况下，我考虑使用规则引擎，但规则引擎的技术风险（*）总是高于预期收益。规则（直到现在）从来没有那么复杂，需要声明性编程模型。
如果您使用面向对象的语言，您可以尝试应用规范模式。 Eric Evans 和 Martin Fowler 编写了更详细的解释，您可以在此处找到。或者，您可以编写自己的简单规则引擎。
(*) 脚注：您需要以某种方式将规则引擎嵌入到您的应用程序中，该应用程序很可能是用某种面向对象的语言编写的。因此，存在一些您必须跨越的技术界限。每一座这样的桥梁都存在技术风险。我曾经亲眼目睹过一个 Java Web 应用程序使用用 C 编写的规则引擎。一开始，C 程序有时会生成核心转储并破坏整个 Web 应用程序。
I do not think that the evaluation of the rules will be the challenge. I think that the greater challenge is to parse the rules that the user can enter. For parsing the rules you should consider to create some DSL. Martin Fowler has some thoughts about this here. Then maybe ANTLR then might be worth a look.
For the evaluation part: I work in the finance industry and there are also complicated rules, but I never had to use a rule engine. The means of an imperative programming language (in my case C#) were (until now) sufficient. For some occasions I was considering a rules engine, but the technological risks(*) of a rule engine were always higher than the expected benefits. The rules were (until now) never that complicated, that declarative programming model was needed.
If you are using a object oriented language you can try to apply the Specification Pattern. Eric Evans and Martin Fowler have written a more detailed explanation, which you can find here. Alternatively you can write your own simple rule engine.
(*) Footnote: Somehow you will need to embed the rule engine into your application which is very likely written in some object oriented language. So there are some technological boundaries, which you have to bridge. Every such bridge is a technological risk. I had once witnessed a Java web application using a rule engine written in C. At the beginning the C program sometimes produced core dumps and tore down the whole web application.
我认为，与大多数自制与外购决策一样，这始终是您必须亲自做出的权衡。如果您购买了价值 10 万以上的现成解决方案，而您只使用其中的 1%，那么这可能是一笔不明智的花费。然而，如果该产品非常适合，那么您几乎可以肯定您永远不会以更低的价格构建它（假设他们在该特定领域拥有丰富的经验）。
因此，不，只要您不尝试做现成产品所做的所有事情，而只是专注于您需要的特定功能，而不是被构建一个非常好的想法所诱惑，那么您就不会疯狂地重新发明这个轮子。 （但昂贵）非常简单的框架。
I think as with most make vs buy decisions it's always a tradeoff you have to make personally. If you buy an off the shelf solution which costs 100K+ and you're only going to use 1% of it than that is probably some money unwisely spent. However if the product is a perfect fit then you can almost be sure you can never build it for less (assuming they have a lot of experience in that particular field).
So no you're not nuts to reinvent this wheel as long as you're not trying to do everything the off the shelve product does and just focus on the specific functionality you need and not get yourself tempted by the idea of building a very nice (but expensive) framework for something very simple.
100K 并不是小钱，但是一个像样的程序员一年的花费几乎肯定会比这个多 - 你有一个更便宜的程序员可以比一年更快地完成它吗？它会同样好（满足您的需求）还是更好？
100K isn't chump change, but a decent programmer for a year will almost certainly cost more than that - do you have a cheaper programmer that can do it faster than a year? will it be just as good (for your needs) or better?
这不完全是我的领域，我偶然提出这个问题，所以我可能会离开，但我会看看 Wolfram Mathematica。它是一种技术计算环境和多范式（专有）编程语言，支持多种编程风格（包括基于规则和函数式编程）。它的核心有一个非常通用的规则引擎。尽管它的名称和声誉是数学软件（确实如此），但它是一种非常高级的通用编程语言。它的一个子集可以编译为 C。它可以动态加载外部 dll，并且可以与 Java 和 .Net 平台透明地进行互操作。它有一个 Web 版本 - webMathematica（它基于 Java，但是，jsp+Tomcat，但没有人阻止您直接将它与基于 .Net 的 Web 层连接，只需做一些更多的工作）。额外的好处是，如果您需要任何数学计算、分析、绘图、统计，一切都在那里，而且是最先进的。
我认为在 Mathematica 中开发所需的功能应该比在许多其他语言/解决方案中快得多（我用 Mathematica、C、Java 和 Javascript 进行专业编程，因此至少可以比较这些语言）。我认为完整的商业许可证应该是单机（4核）2或3K。它具有多种并行化功能。这种方法中最困难的事情是找到一个有能力的 Mathematica 程序员，但是具有函数/基于规则的编程（例如 LISP / Prolog）背景的人应该能够相当快地掌握东西。另外，如果您需要非常高的性能，它可能不够快 - 我真的不知道它在性能方面与其他规则引擎相比如何。有时，我有机会在 Mathematica 中将某些问题的基于规则的解决方案与编译为 C 的解决方案进行比较，我想说，编写良好的基于规则的代码在性能方面应该处于 Python 的水平，并且平均而言，可能比编译为 C 的速度慢一个数量级左右。但这主要是针对数值/计算或数据操作相关的问题，所以我认为对于本质上基于规则的问题，性能差距可能更小。
我确信的一件事是，在 Mathematica 中，您可以使用少量代码相当轻松地创建任何通用性和复杂性的规则集。它是根据我目前遇到的规则进行探索性编程的最佳工具，开发周期非常短。我邀请您访问 SO 的 Mathematica 标签，看看人们正在用它解决什么类型的问题。对于完全用 Mathematica 语言编写的一个著名项目（1500 万行代码），请查看 WolframAlpha 知识引擎。
This is not quite my field, I came by this question by accident, so I may be off, but I'd take a look at Wolfram Mathematica. It is a technical computing environment and multi-paradigm (proprietary) programming language, supporting many programming styles (including rule-based and functional programming). It has a very general rule engine at its core. Despite the name and reputation as mathematical software (which it is), it is a general-purpose programming language, very high-level. A subset of it can be compiled to C. It can load external dlls dynamically, and it transparently inter-operates with both Java and .Net platforms. It has a web version - webMathematica (which is based on Java however, jsp+Tomcat, but no one stops you from interfacing it with your .Net - based web layer directly, just some more work). The additional benefit is that, if you ever need any mathematical computations, analysis, plots, statistics, it's all there, and state of the art.
I'd think it should be much faster to develop the functionality you need in Mathematica than in many other languages / solutions (I program professionally in Mathematica, C, Java and Javascript, so can at least compare these languages). The full commercial license should be 2 or 3 K for a single machine (4 cores), I think. It has several parallelization features. The hardest thing in this approach would be to find a competent Mathematica programmer, but someone with a background in functional/rule-based programming (LISP / Prolog, say) should be able to pick up things fairly quickly. Also, it may not be sufficiently fast if you need very high performance - I really don't know how it compares in terms of performance with other rule engines. On occasion, I had a chance to compare in Mathematica a rule-based solution for some problem to the one compiled to C, and I'd say well written rule-based code should be on the level of Python in terms of performance, and on the average perhaps one order of magnitude or so slower than the one compiled to C. But that was mostly for numerical/computational or data-manipulation-related problems, so I'd think for problems inherently based on rules, the performance gap could be smaller.
One thing I am sure about is that in Mathematica you can create sets of rules of any generality and complexity fairly easily with a small amount of code. It is a best tool for exploratory programming based on rules that I encountered so far, with a very short development cycle. I invite you to visit the Mathematica tag here at SO to see what types of problems people are solving with it. For one prominent project written entirely in Mathematica language (15 millions lines of code), check out WolframAlpha knowledge engine.
是否有更好的 .net 替代方案？
一种选择是在 .net 代码中使用嵌入式脚本引擎，例如 Iron Python。为您的用户提供一个GUI来制定规则，将“规则”转换为Python脚本，调用.Net内部的Python脚本引擎来执行脚本。
我们疯狂地重新发明这个轮子吗？
如果现成的东西无法满足您的需求，那么不行。
Is there a better alternative for .net?
One option is to use an embedded script engine inside your .net code, like Iron Python. Give a GUI for your users to make rules, convert "the rule" to Python script, call the Python script engine inside of .Net to execute the script.
Are we nuts to reinvent this wheel?
If nothing off the shelf meets your needs then No.
问题在于，这些事情与企业独特的运营方式如此紧密地交织在一起，即使不是不可能，也很难有效地使用现成的解决方案。
我用两种不同的方式做了类似的事情。
最近的（在 VS 2005/Framework 2.0 中）是创建一个基本引擎来处理全面的常见最低要求。这将是诸如名称、地址等内容。然后我编写了一系列使用通用接口的扩展 DLL，这些扩展 DLL 将通过反射加载特定类型/区域，例如按州或产品线。高级用户可以使用一个简单的应用程序来创建他们需要的帐户配置（配置存储在数据库中）。如果情况发生变化，则可以修改底层 DLL 或添加新的 DLL。在我参与这个项目的 4 年里，我只需要添加一个新的扩展 DLL，但通常每个月都需要一两个小 mods 来遵守规则。
在一个更早的 VB6 项目中，我使用引导式 VBScript 为高级用户提供编写某些规则的能力。尽管用户非常了解 Excel 脚本，并且编写了一个向导界面来帮助他们完成需要做的事情，但他们通常只是让我负责编写规则。这个计划有点适得其反，所以这就是为什么我后来没有再次使用它，而是选择了更多“检查这个，选择那个”的规则构建方法。
The problem is that these things are so intertwined with the how a business uniquely operates it's difficult, if not impossible, to effectively use an off the shelf solution.
I've done something like this two different ways.
The most recent (in VS 2005/Framework 2.0) was to create a base engine that handled the common minimum requirements that would be the case across the board. This would be stuff like name, address, etc. Then I wrote a series of extension DLLs that used common interfaces would be loaded via reflection for specific types/regions, for example, by state or product line. Power users could use a simple app to create an account configuration they needed (configurations were stored in a DB). If things changed, the underlying DLL could be modified or a new one added. I only had to add one new extension DLL during the 4 years I was on this project but there were typically one or two small mods needed a month to the rules.
In a much earlier VB6 project I used a guided VBScript to provide power users with the ability to code certain rules. Although the users knew Excel scripting well and a wizard interface was written to help them do what they needed to do they usually just gave me the job of coding the rules. That plan sort of backfired so that's why I didn't use it again later but instead opted for a more "check this, select that" approach to rule building.
如果您的规则很简单，那么编写自己的引擎是可行的。它们变得越复杂，维护它所需的时间就越多。
您可以使用 Drools Server 来执行您的规则，并且仍然使用 .NET 或您喜欢的任何语言来执行您的主要应用程序。 Drools Server 部分仍然需要 Java。
Writing your own engine works if your rules are simple. The more complicated they get, the more time it will take to maintain it.
You can use Drools Server to execute your rules and still do your main application with .NET or whatever language you like. You still need Java for the Drools Server part.