构建一个可能具有具有自定义业务规则的无限类的解决方案
我正在开发一个“智能”问题跟踪应用程序，该应用程序需要在实际允许提交之前确定是否可以在票证中提交特定问题。
我目前遇到的设计问题是，我可以有许多不同类型的“可提交”问题，每个问题都有自己独特的业务逻辑，决定问题是否可以实际提交。从我的设计笔记来看，我有以下条件：
- 支持多个问题（未知数量，理论上可能是无限的）
- 每个问题都与特定的货件直接相关（即用户选择他们的问题，然后提示选择/输入他们的货件） 每个问题
- 都有自己的自定义验证/业务规则（数据由发货提供），用于确定问题是否可以继续进行。例子是：
- 如果问题属于损坏索赔，则必须在 60 天内提取货件。
- 如果问题是取消/退款，则无法发送货件状态。
这个想法几乎就像一个保险处理应用程序，但所有信息已经通过询问货件提供，而不必依赖用户输入（例如，我不需要询问货件何时发送，我可以询问货件对象因为它是 PickupDate），并且只有两种结果：1）该问题可以打开一个案例，或者 2）不，该问题不能有一个案例（又名“运气不好”选项）。在架构方面，即使我使用某种可以支持多种类型问题的STRATEGY 模式，也需要为每种派生类型的问题创建一个自定义类。例如，我需要一个 DamageClaimIssue 和一个 CancellationRequestIssue ，谁知道还有什么；这对开发人员来说似乎很麻烦，因为几乎可以随心所欲地添加新类型，并且需要开发人员启动新的派生类并实现验证逻辑，然后重新编译和重新部署。
使用策略是处理此类问题的最佳方法，还是我忽略了某些事情？理论上，我想让架构足够通用以适应不同的问题（我知道会有超过 2-3 个，我只是不知道它们到底是什么），但我不想去使用 XML 或类似的整体工作流引擎的途径，让事物可以通过动态逻辑动态定义。我必须使用标准 .NET 3.5 库（即不像 WCF 或 Workflow Foundation 那样）。
有什么建议或指示可以让我朝着正确的方向前进吗？
I'm working on a "smart" issue tracking application that needs to determine if a particular issue can be submitted in a ticket before actually allowing submission.
The design issue I'm running into at present is the fact there can me many different types of "submittable" issues, each with its own unique business logic that determines if the issue can actually be submitted. From my design notes I have the following conditions:
- Supports multiple issues (unknown number, in theory could be infinite)
- Each issue is directly related to a specific shipment (i.e. user selects their issue, and then is prompted to choose/enter the shipment they have the issue with)
- Each issue has its own custom validations/business rules (data is provided by the shipment) that determines if the issue can proceed. Examples would be:
- If the issue is a Damage Claim, the shipment has to have been picked up within 60 days.
- If the issue is a Cancellation/Refund, the shipment status can't be delivered.
The idea is almost like an insurance processing application but all the information is already provided by asking the shipment, instead of having to rely on user input (e.g. I don't need to ask when the shipment was sent, I can ask the shipment object for it's PickupDate), and there are only two outcomes: 1) The issue can have a case opened, or 2) No, the issue cannot have a case (aka the "tough luck" option). On the architectural end, even if I'm using some kind of STRATEGY pattern that can support multiple types of issues, it would require a custom class to be created for every derived type of issue. For instance I would need a DamageClaimIssue and a CancellationRequestIssue and who knows what else; this seems cumbersome on the developer side since new types can be added almost at a whim and would require a developer to spin up a new derived class and implement the validation logic, and then recompile and redeploy.
Is using Strategy the best way to handle an issue like this, or am I overlooking something? In theory I'd like to make the architecture generic enough to accommodate different issues (I know there will be more than 2-3, I just don't know what they will be exactly), but I don't want to go the route of having some monolithic workflow engine using XML or similar that lets things get defined on-the-fly with dynamic logic. I have to use standard .NET 3.5 libraries (i.e. nothing like WCF or Workflow Foundation).
Any suggestions or pointers to set me in the right direction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这里要问的第一件事是：谁应该负责定义系统中的新类型问题？
当我正确理解你的时候，它应该是一个用户（也许不是每个用户，而是一个“高级用户”），而不是你的系统的开发人员。因此，您需要一个通用的问题类型，或者一些问题类型，这些问题类型不应该太具体，并且可以通过用户给出的参数进一步细化。关于验证/业务规则：您可以尝试为此定义一个 DSL，其中用户可以自己定义这些规则。此 DSL 中定义的规则可以作为类型定义的一部分存储，也许存储在数据库中，因此在应用验证时，引擎必须解释 DSL 代码。
当然，困难的部分是为您的目的定义一个好的 DSL，足够容易被用户理解并且足够灵活以让他们描述他们需要的每条规则。
The first thing to ask here is: who shall be responsible for defining new types of issues in your system?
When I understood you correctly, it should be a user (perhaps not every user, but a "power user") and not the developers of your system. So you need a generic issue type, or a handful of issue types which should not be too specific and can be further refined by parameters given by the user. Concerning validations/business rules: you can try to define a DSL for that, in which a user can define these rules by himself. Rules defined in this DSL can be stored as part of the type definition, perhaps in a database, so DSL code must be interpreted by your engine when the validation applies.
Of course, the hard part is to define a good DSL for your purpose, easy enough to be understood by users and flexible enough to let them describe every rule they need.
我认为医生的答案很好，尽管我会首先研究规则引擎，因为它听起来像是您需要的东西。为什么要重新发明轮子？您应该能够找到开源和付费版本。
我们最近使用了 IBM 工具 iLog 的 .Net 端口；我不能说这很无痛，但它确实起到了作用。用户可以根据记忆在 Excel 中编辑规则并导入到应用程序中。
我唯一的其他建议是让事情尽可能简单。很可能某个地方会出现优雅的“混乱”规则等（其本身很复杂），请确保其他所有内容都尽可能简单 - 您不想要复杂/混乱的部署/升级/版本控制情况。
I think Doc's answer is good, although I would investigate rules engines first as it sounds like the sort of thing you need. Why re-invent the wheel? You should be able to find open source and paid versions.
We used a .Net port of an IBM tool called iLog recently; I can;t say it was painless but it did the job. From memory users could edit rules in Excel and import into the app.
The only other bit of advice I have to to keep things as simple as possible. It's likely that somewhere there will be an elegant "mess" of rules, etc (which in themselves will be complex) make sure you keep everything else as simple as you can - you don't want a complex / messy deployment / upgrade / versioning situation.
我建议使用业务规则引擎系统，例如 Java 中的 drools。
http://droolsdotnet.codehaus.org/
I would suggest using a Business Rule Engine System like drools in Java.
http://droolsdotnet.codehaus.org/