We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 9 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(1)
有许多可用于 ASP.Net 的业务规则引擎; Windows Workflow Foundation、BizTalk 业务规则引擎,求解器基础,流洞察,以及响应式框架。 Google 还透露了更多内容,例如简单规则引擎和自定义规则引擎。
如果一个问题有很多解决方案,那就说明没有一个解决方案是好的,这是我使用规则引擎的经验。我调查了 WWF,我的经验是,实现引擎和定义规则比简单地在应用程序逻辑中编写规则更困难且更容易出错。
我不鼓励使用二进制格式或图形 DSL。根据我的经验,它们很难更改、调试、搜索和维护。
我的建议是使用熟悉的、最终用户可理解的、特定领域的、基于文本的语言来实施规则。哪种语言取决于您所在的领域以及您的最终用户熟悉的语言。调查竞争产品和实施,看看您的领域中已经使用了什么。
There are many business rules engines available for ASP.Net; Windows Workflow Foundation, BizTalk Business Rule Engine, Solver Foundation, Stream Insight, and Reactive Framework. Google reveals many more, such as Simple Rule Engine and Custom Rule Engine.
If there are many solutions to a problem, that is a clue none of them are any good, and that has been my experience using rule engines. I investigated WWF, and my experience was that implementing the engine and defining rules was more difficult and error-prone than simply coding the rules in the application logic.
I discourage binary-format or graphical DSLs. In my experience they are very hard to change, debug, search, and maintain.
My advice is to implement the rules in a familiar, end-user-understandable, domain-specific, text-based language. Which language will depend on what domain you are working in, and what languages your end-users are familiar with. Investigate competing products and implementations to see what is already being used in your domain.