在我正在开发的 Web 应用程序中，项目可以经过多个状态（例如工作流程），并且在每个工作流程之后可以在每个步骤之后运行一个规则，该规则可以停止流程或显示其他消息。
这些规则应该如何定义？
我正在考虑每条规则一个 dll（并将它们与 MEF 或事件连接），但一个应用程序可能有 200-300 个客户，每个客户都有一些规则，这些规则会变成很多 dll。
更新：
这些规则可能如下所示。假设您提交了一张发票，但您只想在其超过一定金额时从审批者那里授权，那么将调用这样的规则来返回 true 或 false，然后相应地继续。
干杯。
In a web application i'm working on, items can pass through multiple states (eg. workflow) and after each workflow a rule can be run after each step which can stop the process or display additional messages.
How should these rules be defined?
I was thinking about a dll per rule (and hooking them up either with MEF or events) but one application could have 200-300 customers in it each with a few rules which becomes a lot of dlls.
Update:
These rules could be like the following. Say you submit an invoice but you only want to authorize it from your approver if its over a certain amount, then a rule like this would be invoked to return true or false and then proceed accordingly.
Cheers.
发布评论
评论（4）
听起来像一个应用程序可能会受益于使用用 Ruby 或 Python 等动态语言编写的业务规则。 IronPython 与用 C# 或 VB.NET 编写的应用程序完美集成。您可以在 Web 应用程序中创建 DLR ScriptEngine 和 ScriptScope，根据客户端 ID 参数注入用动态语言编写的规则，以与实时普通旧 .NET 对象 (PONO) 进行交互。您可以将数百条规则保存在数据库中，因为它们只是文本（例如 Python 源代码）。查看此博客我写的帖子展示了如何将动态业务规则注入到 .NET 应用程序中。
Sounds like an application that might benefit from using business rules written in a dynamic language like Ruby or Python. IronPython integrates nicely with applications written in C# or VB.NET. You could create a DLR ScriptEngine and ScriptScope in your web application, inject rules written in the dynamic language based on a client ID parameter to interact with your live Plain Old .NET Objects (PONO). You could keep your hundreds of rules in a database because they are just text (Python source code for example). Check out this blog post I wrote which shows how to inject dynamic business rules into a .NET application.
这可能是 .Net 工作流基础
This might be a good candidate for .Net Workflow Foundation
假设您的工作流引擎是数据库驱动的，您可以通过添加公司 ID 字段来区分您的工作流定义。您必须在涉及工作流程的每个地方实施此操作，检查它是什么公司 ID，并相应地加载工作流程。您还必须分别为每个公司 ID 创建工作流程。
这听起来很乏味，但实际上非常简单且容易实现。
然后您可以进一步定义哪个用户使用哪个公司ID。或者，如果您确定每个用户将使用不同的工作流程包，您可以使用用户 ID 而不是中介公司 ID。
Assuming your workflow engine is database driven, you can distinguish your workflow definition by adding a company id field. You will have to implement this in everywhere workflow is involved, checking what company id it is, and load workflow accordingly. You will also have to create the workflow for each company id separately.
This sounds tedious, but it is actually quite simple and easy to get right.
Then you can further define which user uses which company id. Or if you are certain each user will use different workflow packages, you can use user id instead of the intermediary company id.
我发现这篇文章链接的内容对于多客户系统来说是一个有趣的阅读：
http://ayende.com/Blog/archive/2008/08/13/Mutli-Tenancy--multi-tenant-apps-and-frameworks.aspx
I have found stuff linked from this post to be an interesting read on multi-customer systems:
http://ayende.com/Blog/archive/2008/08/13/Mutli-Tenancy--multi-tenant-apps-and-frameworks.aspx