验证类数据答案

【问题标题】：Validating Class Data验证类数据
【发布时间】：2009-03-18 15:32:36
【问题描述】：

在我的应用程序中，我正在创建一系列验证类来检查，例如，用户输入的类的 Name 属性（来自 WinForm）不超过数据库中 varchar() 的大小。

目前，如果名称字段太大，验证代码将抛出自定义异常。（自定义异常，当被 UI 捕获时，将在 MessageBox 中显示自定义异常消息，而不是我的常规异常的通用错误表单。）验证类在应用程序的类库中，并且范围为 Friend。流程如下所示：

WinForms 使用的 DLL 的公共服务层 --(calls)--> Friend Validation Layer
WinForms 使用的 DLL 的公共服务层 --（调用）--> Friend 数据访问层（如果验证成功）。

简化示例：

Public Shared Sub CreateCustomer(cust as Customer)
    Validation.Customer.ValidateForCreate(cust) ' scoped as Friend
    Dal.Customer.Create(cust) ' scoped as Friend
End Sub

当验证失败时，让验证层向 UI 抛出自定义异常是“智能”设计吗？

仅从验证层返回 True/False 以及失败的字符串消息，并让服务层处理抛出异常是否更好？

仅从验证层返回 True/False，并让服务层将 True/False 与失败的字符串消息一起冒泡到 UI 是否更好？

我正在尝试保持面向对象的方法。我的观点是抛出自定义异常并不会违反 OOP 原则，但我希望有其他意见 :)

【问题讨论】：

假设在一个“新客户”中实际上存在多个业务规则违规行为，您是一次性捕获所有违规行为并将其呈现在 UI 中，还是在第一次违规时失败？跨度>
嗯。我打算建议返回一组“违规”将是自定义异常的一个很好的理由。只有您知道您的要求，但我担心用户可能会感到沮丧......
我正在考虑这个问题，但我认为对于用户来说，得到 5 个错误的列表，纠正一个，得到一个 4 个错误的列表，纠正一个，一个列表 3 等。我认为一次看到这么多错误会更令人困惑。意见？
我大概是最后一个给“用户”很多赞誉的人，但是如果向用户展示了 5 个错误的列表，是什么阻止他们纠正所有 5 个问题并重新提交？
如果5件事的消息在消息框中，他们就不会记得了。但是，这并不意味着我不能做额外的工作，例如，为错误的条目更改 TextBox 的背景颜色......如果时间表允许额外的工作;)

标签： oop error-handling theory validation

【解决方案1】：

AFAIK 异常机制实际上是 OOP 方法的核心，并且实际上在将其内置到编程语言中时受到鼓励。我想说让你的验证抛出一个自定义异常是一件非常好的事情，特别是如果你有几个自定义异常（NameTooLongException、NameIncludesNonStandardCharactersException...），这些异常是自记录的，并且对于未来的代码维护者来说很容易阅读。

一旦您的异常到达您的服务层，您可以决定是捕获并处理它（这取决于您的业务逻辑）还是让它一直传递到 UI。如果异常带有有意义的错误消息并且总是合适的，那么让 UI 将其呈现给用户也许不是一个坏主意。（请记住，您可能希望在某些时候将您的应用程序国际化，在这种情况下，消息需要使用正确的语言。）

我的观点是，层分离虽然有时纯粹是逻辑上的，但有其原因，不应该从后端抛出异常到前端，但这更像是一种指导而不是规则。归根结底，做需要做的事情，不要过度考虑设计。

希望这会有所帮助...

尤瓦尔=8-)

【讨论】：