0

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

目前，如果 Name 字段太大，验证代码将抛出自定义异常。（自定义异常，当被 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 原则，但我想要其他意见:)

4

1 回答 1

1

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

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

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

希望这会有所帮助...

尤瓦尔=8-)

于 2009-03-18T15:48:47.990 回答