规则引擎的使用如何影响应用程序的设计、实现和性能？

Question

我对规则引擎的能力感兴趣：

• 启动并迭代业务驱动逻辑
• 让“业务用户”执行这些规则的实际修改，而不是开发人员。
• 理解一般的业务规则

此外，使用规则引擎是否会影响应用程序的质量？

如果将规则引擎部署到1台机器的设置中，而不是使用数千台机器部署到基于多层云的分布式体系结构，那么规则引擎的使用会改变吗？会有什么不同？

Answer 1

关于是否公开非技术人员修改业务规则的接口的决定在很大程度上取决于几个因素，包括项目目标、项目成本、项目寿命以及项目中已知与未知的比率。

例如，如果我相信没有人会使用规则接口，那么我可能会选择不实现它。然而，如果我有理由相信更改将是频繁的，不同的最终用户会期望不同的规则到位，那么我将考虑构建这样的功能。

我选择在一个项目中这样做，而且这个特性被广泛使用花了很多年的时间。我怀疑我们最终会有最终用户想要自己定制东西，所以我们将这个功能一分为二地实现。

它最初是一些只有某些人可以使用的东西，比如开发人员或管理员。这个界面很笨重，但是如果你知道你在做什么的话，它是可以使用的。但是，当产品接近完成时，规则引擎后端逻辑就派上了用场，我们的设计团队为它提供了一个漂亮的面向客户的用户界面。

如果我这样做是不同的，我可能选择一个不同的数据库架构，仅仅是因为学习曲线很高。但是简单地说，早期构建它会导致许多客户以后面对特性，而不必回到代码中并重构它来包含所有的动态规则。

Answer 2

如果我要这样做，我将创建一种特定于域的语言来表达规则，并且可能会给biz类型一个UI来根据请求修改它。然后使用函数式语言(如Haskell、Lisp或Erlang)来计算规则。

如果需要大规模并行，我将使用Erlang，它的并发性非常好。使用Erlang可以很好地从1个节点扩展到100个或更多节点。

如果您认为这些规则是将应用于数据集的代数，那么就更容易逻辑出代码中的需要，并向自己(或经理)证明它是正确的。这是功能语言对你有利的地方之一。

Answer 3

我编写了一个基于WF (windows工作流基金会)的应用程序。我的老板( DBA)确信WF可以执行多线程，而不需要计划并发性。内存被彻底划分了，但是有太多的问题，我无法在几个段落中解释它，它只是与您的question...so略有关联，我继续说。

能够迭代BL：

我们做得很好。

允许非技术人员“构建应用程序”：

如果体系结构有效且非技术人员理解技术限制，WF就能很好地做到这一点.我们的没有。

一般理解业务规则的能力：

有一些外接程序可以做一些基本的事情，就像sharepoint可以自动化工作流一样。我没有进入这些项目。

软件的质量保证：

平庸。WF并没有很好地达到我们的目的，但是系统设计得很糟糕，我的手也被绑住了。

申请速度：

慢的。对于开发人员和最终用户来说，学习曲线是相当陡峭的。WF分离内存的方式(如果我记得的话，是应用域)使得跨线程通信、互斥和其他线程概念变得杂乱无章或者根本不起作用。

最后，我编写了一个原型，以证明WF在实现方式上失败了。我用普通的多线程代替了它。性能和代码可读性提高了。这是我第一次申请专业WF。

非技术人员可以相信，在不需要程序员的情况下，几乎任何事情都是可能的，这可能对BL的整个“虚拟下降”产生很大的负面影响；与此相关的社会学问题扼杀了该项目。

如果我可以回去做我的方式:使用传统的线程和通过装饰图案。实现的BL模型，我写了一个概念的证明，使用这些技术，它工作得很好。BL映射应该封装在一个简单的UI中。

更新

在处理并发问题时，我找到了一篇我写的旧文章。代码展示了在并行工作流中打印"hello world“是如何工作的，如果不了解封面下面发生了什么(这就违背了WF抽象的全部目的)。MSDN版主解释了并行活动是如何真正的顺序的高级概述。他的结论基本上是“你需要阅读整本手册”来做一些基本的事情。http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

祝好运。