业务对象“警告”：好的例子/想法？答案

【问题标题】：Business Object "Warnings": Good Examples/Ideas?业务对象“警告”：好的例子/想法？
【发布时间】：2011-04-25 23:28:51
【问题描述】：

我正在尝试为我正在处理的项目中的业务对象提出一个可重复使用的警告片段。在保存我们的一个业务对象之前，有时我们需要警告用户潜在的影响是什么。假设我的业务对象被命名为“公司”。 Company.Delete() 将摆脱公司，而不是真正关心发生了什么。那家公司可能有 10,000 名员工，如果这么容易让他们意外失业，他们会非常失望......

所以 UI 需要一种方式来查看类似的内容：

删除“A 公司”将使 10,000 名工人上街。
删除“A公司”将留下1,000,000名股东无用的股票。

所以我可以创建一个像 Company.GetWarnings() 这样的函数，它返回一些要显示的字符串，但我想要比这更好的东西。如果 Company.GetWarnings() 返回上面的第一个警告，我希望 UI 能够知道该警告的含义。例如，如果出现第一个警告，UI 会知道它的含义并通过提供如下链接来处理这种情况：

删除“A公司”将使10,000名工人上街。
- 您想为这些员工找到新工作吗？ '点击这里'

或者也许另一个业务对象会使用 Company.GetWarnings() 并且知道一些工人会失业，它可以自动发送遣散费。你明白了……

所以我想这个要求听起来很简单，但我有点迷失在小细节上。主要是，我可以给 GetWarnings() 什么样的结构以便它返回：

警告消息。
某种方式来识别它是什么类型的消息。

让我来回答我的问题：

有没有人有任何最佳实践、示例或建议来实施这种警告系统？我主要关心的是#2。会有大量不同类型的警告消息，所以我不想只返回说...一个字典，其中 int 是警告类型的 Id。这将很难快速管理。

感谢您提供的任何建议。

【问题讨论】：

除非他们需要信息，否则很难让人们阅读任何信息
我的感觉是，无论发生什么，您都需要列出所有可能的警告“类型”......无论如何，您都需要它来确定要完成的操作，具体取决于关于警告的类型，你不觉得吗？
@tsimbalar：绝对正确，但我正在尝试找到一种好方法来组织所有已定义的警告类型，而无需使用包含所有警告的巨大枚举。

标签： c# design-patterns business-objects

【解决方案1】：

您可以使用多态性来定义抽象警告和具体警告的层次结构：

abstract class Warning {
  public String Description { get; protected set; }
  public abstract IEnumerable<Consequence> Consequences { get; }
  public abstract IEnumerable<Action> Actions { get; }
}

class CompanyDeletionWarning : Warning {
  public override IEnumerable<Consequence> Consequences { get { ... } }
  public override IEnumerable<Action> Actions { get { ... } }
}

挑战在于提出一个足够通用的抽象基类，以处理您可能遇到的所有警告。您可能还必须在聚合对象中使用这种方法，例如Action 可以是带有 Execute 方法的抽象基类。然后你可以创建一个具体的FindNewWorkForEmployeesAction。

如果您愿意，也可以使用接口，例如IWarning.

【讨论】：

【解决方案2】：

我想可能的警告类型会非常有限......也许Enum 是个好主意？

enum WarningType{
    MayPutWorkersOnTheStreet,
    WillNotPleaseStakeholders
    /*...*/
}

你可以定义一个小类（实际上它可以是一个通用的 Warning<T> ，T 是 Company 或其他东西，你可以跟踪错误的来源。

public class Warning<T>{
    public Warning(WarningType type, String msg, T source){
         //you get the idea */  
    }
}

然后您的验证将生成一个这样的Warnings 列表

public IEnumerable<Warning<Company>> GetWarnings(){
   // something here
}

这只是一个快速的想法......

【讨论】：

我在考虑使用 Enums，但警告的数量实际上会很大。不过，将警告类型限制在它们所属的类是一个好主意。暂时赞成，如果没有更好的想法，以后会接受。
@Ocelot20 ：是的，我实际上看到关于大量警告的限制有点太晚了，在发布答案后重新阅读问题......我对建议的答案很感兴趣，尽管！ :-)

【解决方案3】：

嘿，豹猫，在我看来，这不是数据驱动的问题，也不依赖于业务对象本身。您需要某种 ActionValidator 来检查业务逻辑并负责这些检查。

MacX

【讨论】：

你能详细解释一下吗？警告在很大程度上取决于业务对象，因为是对象的新/更改属性驱动了警告的出现。
您提到的更改是在 UI 中进行的。恕我直言，UI 负责将有效数据传递给另一层（业务层）。

【解决方案4】：

如果您能够使用 3rd 方框架...我建议您使用 CSLA.net。这是一个非常好的业务逻辑框架。如果你不能在这个项目中使用它，你至少可以看一下源代码，看看他是如何在业务规则中进行警告的。源代码免费提供。

【讨论】：