业务对象、验证和异常

Question

我一直在阅读一些有关异常及其使用的问题和答案。 似乎有一种强烈的观点认为，仅应针对异常、未处理的情况提出异常。 因此，这让我想知道验证如何与业务对象一起工作。

假设我有一个业务对象，其中包含对象属性的 getter/setter。 假设我需要验证该值是否在 10 到 20 之间。这是一条业务规则，因此它属于我的业务对象。 所以这对我来说似乎意味着验证代码进入我的设置器中。 现在我将 UI 数据绑定到数据对象的属性。 用户输入 5，因此规则需要失败，并且不允许用户移出文本框。 。 UI 数据绑定到属性，因此将调用 setter、检查规则并失败。 如果我从业务对象中引发异常，表明规则失败，UI 会接收到该异常。 但这似乎违背了异常的首选用法。 鉴于它是一个二传手，您实际上不会为二传手获得“结果”。 如果我在对象上设置另一个标志，则意味着 UI 必须在每次 UI 交互后检查该标志。

那么验证应该如何进行呢？

编辑：我可能在这里使用了一个过于简化的示例。 像上面的范围检查之类的事情可以通过 UI 轻松处理，但是如果验证更复杂怎么办，例如业务对象根据输入计算一个数字，如果计算出的数字超出范围，则应该拒绝它。 这是更复杂的逻辑，不应该出现在 UI 中。

还考虑根据已输入的字段输入进一步的数据。 例如，我必须在订单上输入一个项目才能获取某些信息，例如现有库存、当前成本等。用户可能需要此信息来决定进一步输入（例如要订购多少单位），或者订单中可能需要此信息以便进一步验证。 如果该项目无效，用户是否应该能够输入其他字段？ 重点是什么？

Answer 1

我认为这取决于你的商业模式有多重要。 如果你想走DDD之路，你的模型是最重要的。 因此，您希望它始终处于有效状态。

在我看来，大多数人都试图对域对象做太多事情（与视图通信、保存到数据库等），但有时您需要更多层和更好的关注点分离，即一个或多个视图模型。 然后，您可以在视图模型上无例外地应用验证（对于不同的上下文，例如 Web 服务/网站/等，验证可能会有所不同），并将异常验证保留在业务模型中（以防止模型被损坏）。 您将需要一个（或多个）应用程序服务层来将您的视图模型与业务模型进行映射。 业务对象不应该被通常与特定框架（例如 NHibernate Validator）相关的验证属性所污染。

Answer 2

如果输入超出了业务对象实现的业务规则，我会说这是业务对象未处理的情况。 因此我会抛出一个异常。 即使在您的示例中设置器会“处理”5，但业务对象不会。

对于更复杂的输入组合，需要一种验证方法，否则您最终会得到分散在各处的相当复杂的验证。

在我看来，您必须根据允许/禁止输入的复杂性来决定走哪条路。

Answer 3

我认为这是一个可以抛出异常的例子。 您的属性可能没有任何上下文来纠正问题，因为这样的异常是正常的，并且调用代码应该处理这种情况（如果可能）。

Answer 4

如果数据无效，您是否考虑过在设置器中引发事件？ 这将避免引发异常的问题，并且无需显式检查对象是否有“无效”标志。 您甚至可以传递一个参数来指示哪个字段验证失败，以使其更可重用。

如果需要，事件处理程序应该能够将焦点放回到适当的控件上，并且它可以包含通知用户错误所需的任何代码。 此外，您可以简单地拒绝连接事件处理程序，并在需要时忽略验证失败。

Answer 5

根据我的经验，验证规则很少在应用程序的所有屏幕/表单/流程中通用。 像这样的场景很常见：在添加页面上，Person 对象没有姓氏可能没问题，但在编辑页面上它必须有姓氏。 在这种情况下，我开始相信验证应该在对象之外进行，或者应该将规则注入到对象中，以便规则可以在给定的上下文中更改。 有效/无效应该是验证后对象的显式状态，或者可以通过检查失败规则的集合来派生的状态。 恕我直言，失败的业务规则也不例外。

Answer 6

在你的情况下抛出异常是可以的。 您可以将这种情况视为真正的异常，因为某些东西正在尝试将整数设置为字符串（例如）。 业务规则缺乏对您的视图的了解意味着他们应该认为这种情况是例外的并将其返回到视图。

在将输入值发送到业务层之前是否对其进行验证取决于您，我认为只要您在整个应用程序中遵循相同的标准，那么您最终将得到干净且可读的代码。

您可以使用上面指定的 spring 框架，但要小心，因为链接文档的大部分内容都指示编写非强类型的代码，IE 可能会在运行时出现错误，而这些错误在编译时无法发现。 这是我尽力避免的事情。

目前我们的做法是从屏幕上获取所有输入值，将它们绑定到数据模型对象，如果值错误则抛出异常。

Answer 7

您可能想考虑Spring 框架采用的方法。 如果您使用 Java（或 .NET），则可以按原样使用 Spring，但即使您不使用，您仍然可以使用该模式； 您只需要编写自己的实现即可。

Answer 8

正如 Paul Stovell 的文章提到的，您可以在您的业务中实施无差错验证通过实现 IDataErrorInfo 接口来获取对象。 这样做将允许通过 WinForm 的 ErrorProvider 和 WPF 的绑定验证规则。 验证对象属性的逻辑存储在一个方法中，而不是存储在每个属性 getter 中，并且您不一定必须求助于 CSLA 或验证应用程序块等框架。

至于阻止用户将焦点移出文本框：
首先，这通常不是最佳实践。 用户可能想要不按顺序填写表单，或者，如果验证规则依赖于多个控件的结果，则用户可能必须填写虚拟值才能离开一个控件以设置另一个控件。 也就是说，这可以通过将表单的 AllowValidate 属性设置为其默认值 EnableAllowFocusChange 并订阅 Control.Validating 事件来实现：

    private void textBox1_Validating(object sender, CancelEventArgs e)
    {
        if (textBox1.Text != String.Empty)
        {
            errorProvider1.SetError(sender as Control, "Can not be empty");
            e.Cancel = true;
        }
        else
        {
            errorProvider1.SetError(sender as Control, "");
        }
    }

为此使用存储在业务对象中的规则验证有点棘手，因为在焦点更改和更新数据绑定业务对象之前调用 Validating 事件。

Answer 9

我倾向于认为，当传递的值违反其业务规则时，业务对象应该抛出异常。 然而，winforms 2.0 数据绑定架构似乎采取了相反的假设，因此大多数人都自然而然地支持这种架构。

我同意 shabbyrobe 的最后一个答案，即业务对象应该构建为可用并在多种环境中正确工作，而不仅仅是 winforms 环境，例如，业务对象可以在 SOA 类型的 Web 服务、命令行界面、asp 中使用.net 等。在所有这些情况下，对象应正确运行并保护自身免受无效数据的影响。

经常被忽视的一个方面是管理 1-1、1-n 或 nn 关系中的对象之间的协作时会发生什么，这些对象是否也接受无效协作者的添加，并且只维护一个应该检查或应该检查的无效状态标志它主动拒绝添加无效的协作。 我必须承认我深受 Jill Nicola 等人的 Streamlined Object Modeling (SOM) 方法的影响。 但还有什么是合乎逻辑的呢？

接下来的事情是如何使用 Windows 窗体。 我正在考虑为这些场景的业务对象创建一个 UI 包装器。

Answer 10

这取决于您将执行何种类型的验证以及在何处执行。 我认为应用程序的每一层都可以轻松地保护免受不良数据的影响，而且这太容易了，因此不值得。

考虑多层应用程序以及每层的验证要求/设施。 中间层，对象，是这里似乎有争议的一层。

• 数据库
  通过列约束和引用完整性保护自身免受无效状态的影响，这将导致应用程序的数据库代码抛出异常

• Object
  ?

• ASP.NET/Windows 窗体
  使用验证器例程和/或控件保护表单的状态（而不是对象），而不使用异常（winforms 不附带验证器，但 msdn 描述如何实现它们)

假设您有一个包含酒店房间列表的表，每行都有一个床位数量一栏称为“床位”。 该列最合理的数据类型是无符号小整数*。 您还有一个普通的 ole 对象，其具有名为“Beds”的 Int16* 属性。 问题是您可以将 -4555 粘贴到 Int16 中，但是当您将数据保存到数据库时，您将收到异常。 这很好 - 我的数据库不应该允许说酒店房间的床位少于零，因为酒店房间的床位不能少于零。

* 如果你的数据库可以代表它，但我们假设它可以
* 我知道您可以使用 ushort在 C# 中，但出于本示例的目的，我们假设您不能。

对于对象是否应该代表您的业务实体，或者它们是否应该代表表单的状态，存在一些混淆。 当然，在 ASP.NET 和 Windows 窗体中，窗体完全能够处理和验证其自身状态。 如果 ASP.NET 表单上有一个文本框，将用于填充相同的 Int16 字段，则您可能在页面上放置了一个 RangeValidator 控件，该控件在将输入分配给对象之前测试输入。 它会阻止您输入小于零的值，并且可能会阻止您输入大于（例如）30 的值，这希望足以满足您能想象到的跳蚤出没最严重的旅馆的需求。 在回发时，您可能会在构建对象之前检查页面的 IsValid 属性，从而防止您的对象代表小于零的床，并防止您的 setter 被调用为它应该的值撑不住了

但是您的对象仍然能够表示小于零的床，而且，如果您在不涉及集成了验证的层（您的表单和数据库）的场景中使用该对象，那么您我们运气不好。

为什么你会遇到这种情况？ 这一定是非常特殊的情况！ 因此，您的 setter 在收到无效数据时需要抛出异常。 它永远不应该被抛出，但它可能会被抛出。 您可能正在编写一个 Windows 窗体来管理对象以替换 ASP.NET 窗体，但忘记在填充对象之前验证范围。 您可以在计划任务中使用该对象，其中根本没有用户交互，并且保存到数据库的不同但相关的区域，而不是对象映射到的表。 在后一种情况下，您的对象可能会进入无效状态，但直到其他操作的结果开始受到无效值的影响时您才会知道。 如果您正在检查它们并抛出异常，那就是。

Answer 11

您的业​​务对象应该因错误输入而引发异常，但在正常程序运行过程中决不应该引发这些异常。 我知道这听起来很矛盾，所以我会解释一下。

每个公共方法都应该验证其输入，并在输入不正确时抛出“ArgumentException”。 （私有方法应该使用“Debug.Assert()”验证其输入以简化开发，但这是另一个故事了。）关于验证公共方法（当然还有属性）的输入的规则对于应用程序的每一层都适用。

当然，软件接口的要求应该在接口文档中阐明，调用代码的工作就是确保参数正确并且永远不会抛出异常，这意味着 UI 需要验证在将输入传递给业务对象之前。

虽然上面给出的规则几乎永远不会被打破，但有时业务对象验证可能非常复杂，并且不应将这种复杂性强加到 UI 上。 在这种情况下，BO 的接口最好在接受的内容上留有一定的余地，然后提供显式的 Validate(out string[]) 谓词来检查属性并就需要更改的内容提供反馈。 但请注意，在这种情况下，仍然存在明确定义的接口要求，并且不需要抛出异常（假设调用代码遵循规则）。

按照后一个系统，我几乎从不对属性设置器进行早期验证，因为这种软化使属性的使用变得复杂（但在问题中给出的情况下，我可能会这样做）。 （顺便说一句，请不要仅仅因为字段中有错误数据就阻止我从字段中跳出。当我无法在表单周围跳动时，我会产生幽闭恐惧症！我会在一分钟内返回并修复它，我保证！好吧，我现在感觉好多了，抱歉。）

Answer 12

也许您应该考虑同时进行客户端和服务器端验证。 如果有任何事情未能通过客户端验证，那么如果您的业务对象无效，您可以随意抛出异常。

我使用的一种方法是将自定义属性应用于业务对象属性，它描述了验证规则。 例如：

[MinValue(10), MaxValue(20)]
public int Value { get; set; }

然后可以处理这些属性并用于自动创建客户端和服务器端验证方法，以避免重复业务逻辑的问题。

Answer 13

我肯定会提倡客户端和服务器端验证（或在各个层进行验证）。 当跨物理层或进程进行通信时，这一点尤其重要，因为抛出异常的成本变得越来越昂贵。 此外，等待验证的时间越长，浪费的时间就越多。

至于是否使用异常进行数据验证。 我认为在流程中使用异常是可以的（尽管仍然不是首选），但在流程之外，调用一个方法来验证业务对象（例如在保存之前），并让该方法返回操作的成功以及任何验证错误。 错误并不罕见。

当验证失败时，Microsoft 会从业务对象引发异常。 至少，企业库的验证应用程序块就是这样工作的。

using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;
public class Customer
{
  [StringLengthValidator(0, 20)]
  public string CustomerName;

  public Customer(string customerName)
  {
    this.CustomerName = customerName;
  }
}

Answer 14

异常不应作为验证的正常部分而抛出。 从业务对象内部调用的验证是最后一道防线，只有在 UI 无法检查某些内容时才应该发生。 因此，它们可以像任何其他运行时异常一样对待。

请注意，定义验证规则和应用它们之间存在差异。 您可能希望在业务逻辑层中定义（即编码或注释）业务规则，但从 UI 调用它们，以便可以以适合该特定 UI 的方式处理它们。 不同的 UI 的处理方式会有所不同，例如基于表单的 Web 应用程序与 Ajax Web 应用程序。 异常集验证提供的处理选项非常有限。

许多应用程序重复其验证规则，例如在 JavaScript、域对象约束和数据库约束中。 理想情况下，这些信息只会定义一次，但实现这一点可能具有挑战性，并且需要横向思考。

Answer 15

您可能希望将验证移至 getter 和 setter 之外。 您可以有一个名为 IsValid 的函数或属性来运行所有验证规则。 t 会用所有“破坏的规则”填充字典或哈希表。 该字典将暴露给外界，您可以使用它来填充错误消息。

这是 CSLA.Net 中采用的方法。

Answer 16

我一直很喜欢 Rocky Lhotka 在 CSLA 框架 中的方法（正如 Charles 所提到的）。 一般来说，无论是由 setter 驱动还是通过调用显式 Validate 方法，BrokenRule 对象的集合都是由业务对象在内部维护的。 UI 只需检查对象的 IsValid 方法，该方法又检查 BrokenRules 的数量，并进行适当的处​​理。 或者，您可以轻松地让 Validate 方法引发 UI 可以处理的事件（可能是更简洁的方法）。 您还可以使用 BrokenRules 列表以摘要形式或在相应字段旁边显示错误消息以供使用。 尽管 CSLA 框架是用 .NET 编写的，但总体方法可以用任何语言使用。

我不认为在这种情况下抛出异常是最好的主意。 我绝对遵循这样的思想：异常应该是在特殊情况下出现的，而简单的验证错误则不然。 在我看来，引发 OnValidationFailed 事件将是更干净的选择。

顺便说一句，我从来不喜欢在字段处于无效状态时不让用户离开字段的想法。 在很多情况下，您可能需要暂时离开该字段（也许先设置其他字段），然后再返回并修复无效字段。 我认为这只是不必要的不​​便。

Answer 17

假设您有单独的验证和持久（即保存到数据库）代码，我将执行以下操作：

1. UI 应该执行验证。 不要在这里抛出异常。 您可以提醒用户错误并阻止保存记录。

2. 您的数据库保存代码应该针对错误数据抛出无效参数异常。 在这里这样做是有意义的，因为此时您无法继续写入数据库。 理想情况下，这种情况永远不会发生，因为 UI 应阻止用户保存，但您仍然需要它来确保数据库一致性。 此外，您可能会从 UI 以外的其他地方调用此代码（例如批量更新），其中没有 UI 数据验证。

Answer 18

您想深入了解 Paul Stovell 在数据验证方面的杰出工作。 他在这篇文章中一度总结了自己的想法。 我碰巧分享了他对此事的看法，我在 我自己的库。

用 Paul 的话说，以下是在 setter 中抛出异常的缺点（基于 Name 属性不应为空的示例）：

• 有时您可能确实需要一个空名称。 例如，作为“创建帐户”表单的默认值。
• 如果您在保存之前依赖此方法验证任何数据，您将错过数据已经无效的情况。 我的意思是，如果您从数据库加载一个空名称的帐户并且不更改它，您可能永远不知道它是无效的。
• 如果您不使用数据绑定，则必须使用 try/catch 块编写大量代码来向用户显示这些错误。 当用户填写表单时尝试在表单上显示错误变得非常困难。
• 我不喜欢为非异常的事情抛出异常。 用户将帐户名称设置为“Supercalafragilisticexpialadocious”不是例外，而是错误。 当然，这是个人的事情。
• 这使得获取所有已被违反的规则的列表变得非常困难。 例如，在某些网站上，您会看到诸如“必须输入姓名。必须输入地址。必须输入电子邮件”之类的验证消息。。 为了显示这一点，您将需要大量 try/catch 块。

以下是替代解决方案的基本规则：

1. 拥有无效的业务对象并没有什么问题，只要您不尝试保留它即可。
2. 任何和所有损坏的规则都应该可以从业务对象中检索，以便数据绑定以及您自己的代码可以查看是否存在错误并进行适当的处​​理。