Web 应用程序中的动态业务规则
问候！
在基于网络的项目上工作时，业务规则和逻辑需要由客户定制。 我希望这样做，而不必每次在系统上注册新客户端时都重新编译应用程序。 到目前为止我概述的体系结构是：
- Windows 工作流：创建动态工作流并将其保存到数据库中。
- 反射：创建业务规则接口并使用反射来加载自定义客户端程序集。
- 真正的业务规则引擎
- 实现类似结构图的 IOC 容器。 [zaff：添加了 6/4]
你曾经实现过类似的事情吗？ 如果是这样，您的经验是什么？ 最后我应该探索另一个解决方案吗？
感谢您的帮助！！
Greetings!
Working on a web based project were business rules and logic need to be customized by client. I want to do this without having to recompile the application every time we sign up a new client on the system. The architectures I have outlined so far are:
- Windows Workflow: Creating dynamic workflows and saving them to the database.
- Reflection: Creating a business rules interface and use reflection to load the custom client assembly.
- A true business rules engine
- Implementing an IOC Container like structure map. [zaff: added 6/4]
Have you ever implemented anything similar to this? If so, what is your experience? And finally is there another solution that I should be exploring?
Thanks for your help!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我已经实施了你提到的大部分方法。 答案可能取决于多种因素。
哪些客户角色将对业务规则进行更改（例如业务分析师、开发人员、高级用户等）？ 对业务分析师的有意义的支持可能需要一个在数据库中具有外部化规则的规则引擎和一个可用的 UI。 对开发人员的有意义的支持可能就像利用 MEF 之类的东西一样简单 (http://www.codeplex.com/MEF< /a>）。
您还可能会考虑业务规则需要更改的频率以及可能适用的相关操作要求（例如，主机进程必须保持运行、应用程序域卸载正常等）。 一个好的选择可能需要仔细考虑未来可能的需求和不太可能的需求。
I have implemented most of the approaches you mention. The answer may depend on a variety of factors.
What client role(s) will be making the changes to the business rules (e.g. business analyst, developer, power user, etc.)? Meaningful support for business analysts may require a rules engine with externalized rules in a db and a useable UI. Meaningful support for developers might be as simple as leveraging something like MEF (http://www.codeplex.com/MEF).
You might also factor in how often will the business rules need to be changed and what sorts of associated operational requirements may apply (e.g. host process must remain running, app domain unloading ok, etc.). A good selection may require some careful thought about likely vs. unlikely future needs.
您可以执行数据驱动的业务规则，例如此。 决策树也是一个不错的方法。
您可能还可以将面向方面的编程视为实现业务规则的一种方式。
我对 Rete 归纳规则引擎的唯一注意事项是规则集应保持较小且靠近使用它们的对象。 如果您可以将对象的行为封装在作为其状态一部分的规则引擎中，那就更好了。 我不喜欢将数千条规则转储到单个规则引擎中的“企业”解决方案，该引擎成为企业每个部分的依赖项。
You can do data driven business rules, like this. Decision trees can be a good way to go as well.
You might also think about aspect-oriented programming as a way to implement business rules.
My only caution with a Rete induction rules engine is that the rule sets should be kept small and close to the objects that use them. If you can encapsulate the behavior of an object in a rules engine that's part of its state, all the better. I don't care for the "enterprise" solution that dumps thousands of rules into a singleton rules engine that becomes a dependency for every part of the enterprise.
这可能不是最好的方法，但我的公司已经在几个案例中实施了您的#2选项，并取得了成功。
我们基本上在数据库或配置文件中配置客户端，对于每个客户端，都会有一个查找表，用于存储要调用的类名以执行任何业务操作。 当代码收到客户端 A 的请求时，它会查找要使用的类，并创建它并通过反射执行它。
我不太喜欢将与代码相关的东西放入数据库中，但它实际上工作正常，并且在本例中并不太复杂。
This may not be the best approach, but my company has implemented your #2 option in several cases, with success.
We basically configure clients in a database or config file, and for each client, there would be a lookup table that stores a class name to invoke for whatever business operation to perform. When the code gets a request for client A, it looks up the class to use, and creates it and executes it via reflection.
I'm not a huge fan of putting code-related things in the database, but it actually works ok and is not too complicated in this case.
我建议结合 1 和 3。
但是不要将工作流存储在数据库中，而是将其存储为决策树或规则流（我们这样称呼它们）。
当您拥有可视化、操作驱动的工具（例如 可视化规则。 让业务分析师或支持人员进行更改而无需调整代码也有很多好处。
此外，这些要求都不需要复杂的人工智能工具，例如 RETE 和推理——顺序逻辑是最好的。
I suggest a combination of 1 and 3.
But don’t store the workflow in a database, store it is a decision tree or rule flow (as we call them).
Changing the workflow to accommodate a particular, customer, or federate them to their profile is a simple task when you have a visual, action-driven tool, such as Visual Rules. There is also a lot of benefit to having your business analyst or support person make that change, without having to adjust the code.
Also none of these requirements call for a complicated AI tools such as RETE and inferencing- Sequential Logic is best.
我基于以下开源 .NET 业务规则引擎 NxBRE 创建了一个动态规则引擎。 我使用 Flow 引擎作为动态规则引擎的主要示例。
我使用了您问题中提到的相同架构。
I created a dynamic rule engine based on the following open source .NET Business Rule Engine NxBRE. I used the Flow engine as the primary example for my dynamic rule engine.
I used the same architecture mentioned in your question.
我喜欢 WF，但如果您看过它并决定想要一些不同的东西，您应该看看 K2。 此外，BizTalk 具有 BRE 支持。
I like WF, but if you've looked at it and decided you want something different, you should look at K2. Also, BizTalk has BRE support.