问候！
在基于Web的项目上工作时，业务规则和逻辑需要由客户自定义。我想这样做，而不必每次在系统上注册新客户端时重新编译应用程序。我到目前为止概述的架构是：
你有没有实现类似的东西？如果是这样，你的经历是什么？最后还有另一种我应该探索的解决方案吗？
感谢您的帮助！
答案 0 :(得分：2)
您可以执行数据驱动的业务规则，例如this。决策树也是一种很好的方式。
您也可以将面向方面的编程视为实现业务规则的一种方式。
我对Rete归纳规则引擎的唯一警惕是规则集应保持较小并靠近使用它们的对象。如果您可以将对象的行为封装在属于其状态的规则引擎中，那就更好了。我不关心将数以千计的规则转储到单一规则引擎中的“企业”解决方案，该引擎成为企业每个部分的依赖关系。
答案 1 :(得分：2)
我实施了你提到的大部分方法。答案可能取决于多种因素。
哪些客户角色将对业务规则进行更改（例如业务分析师，开发人员，高级用户等）？对业务分析师的有意义的支持可能需要在db和可用UI中具有外部化规则的规则引擎。对开发人员的有意义的支持可能就像利用MEF（http://www.codeplex.com/MEF）这样的东西一样简单。
您还可能会考虑业务规则需要更改的频率以及可能适用的相关操作要求的类型（例如，主机进程必须保持运行，应用程序域卸载正常等）。一个好的选择可能需要仔细考虑可能与不太可能的未来需求。
答案 2 :(得分：1)
这可能不是最好的方法，但我的公司在几种情况下已经实施了＃2选项，并取得了成功。
我们基本上在数据库或配置文件中配置客户端，并且对于每个客户端，将存在一个查找表，该表存储要为执行的任何业务操作调用的类名。当代码获得客户端A的请求时，它会查找要使用的类，并创建它并通过反射执行它。
我不是很喜欢在数据库中放置与代码相关的东西，但它实际上工作正常，在这种情况下并不太复杂。
答案 3 :(得分：1)
我建议使用1和3的组合。
但是不要将工作流存储在数据库中，存储它是决策树或规则流（我们称之为）。
当您拥有可视化的，动作驱动的工具（例如Visual Rules）时，更改工作流以适应特定客户或将他们联合到他们的配置文件是一项简单的任务。让业务分析师或支持人员进行更改也有很多好处，而无需调整代码。
这些要求也没有一个要求复杂的AI工具，如RETE和推理 - 顺序逻辑是最好的。
答案 4 :(得分：0)
答案 5 :(得分：0)
我基于以下开源.NET业务规则引擎NxBRE创建了一个动态规则引擎。我使用Flow引擎作为动态规则引擎的主要示例。
我使用了你问题中提到的相同架构。