Question

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

目前，如果Name字段太大，验证代码将抛出自定义Exception。（当被UI捕获时，自定义异常将在MessageBox中显示自定义异常消息，而不是常规异常的常规错误形式。）验证类位于应用程序的类库中，并且作为Friend作用域。流程如下：

WinForms使用的DLL的公共服务层 - （调用） - ＆gt;朋友验证层
WinForms使用的DLL的公共服务层 - （调用） - ＆gt;如果验证成功，则为朋友数据访问层。

简化示例：

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以及失败的String消息并让服务层处理抛出异常是否更好？

从验证层返回True / False是否更好的设计，并让服务层向UI冒泡到UI以及失败的String消息？

我正在努力保持面向对象的方法。我的观点是，抛出自定义异常不会破坏OOP原则，但我想要其他意见：）

Answer 1

AFAIK异常机制实际上是OOP方法的核心，实际上鼓励它在编程语言中构建。我要说你的验证抛出一个自定义异常是一件好事，特别是如果你有几个自定义异常（NameTooLongException，NameIncludesNonStandardCharactersException ...），这些异常是自我记录的，并且很容易对未来的代码维护者可读。

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

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

希望这有所帮助...

Yuval = 8 - ）

验证班级数据

1 个答案: