validation - 您在哪里进行验证？

Question

希望您能看到我在下面的场景中描述的问题。如果不清楚，请告诉我。

您的应用程序分为三层，

• 前端UI层，可以是asp.net webform，或者窗口(用于编辑Person数据)
• 中间层业务服务层，编译成dll(PersonServices)
• 数据访问层，编译成dll(PersonRepository)

在我的前端，我想创建一个新的 Person 对象，根据用户在 UI 中输入的内容设置一些属性，例如 FirstName、LastName，然后调用 PersonServices.AddPerson，传递新创建的 Person 。 (AddPerson 不必是静态的，这只是为了简单起见，无论如何，AddPerson 最终都会调用存储库的 AddPerson，然后它将保留数据。)

现在我想听听您的意见是验证。在此过程中的某个地方，需要验证新创建的 Person。您可以在客户端执行此操作，这很简单，但是如果我想验证 PersonServices.AddPerson 方法中的 Person 该怎么办？这将确保我想要保存的任何人都得到验证，并消除对执行工作的 UI 层的任何依赖。或者，可以在 UI 和业务服务器层中进行验证。到目前为止听起来不错吧？

因此，为了简单起见，我将更新 PersonService.AddPerson 方法来执行以下验证检查- 检查 FirstName 和 LastName 是否不为空- 确保我的存储库中尚不存在这个新人员

如果所有验证通过并且 Person 被持久化，则此方法将返回 True；如果验证失败或 Person 未持久化，则返回 False。

但是 AddPerson 返回的这个 bool 值不足以让我在 UI 层向用户提供保存过程失败的明确原因。那么孤独的开发者该怎么办呢？最终，我希望 AddPerson 方法能够确保其要保存的内容有效，如果不是，则能够向我的 UI 层传达其无效的原因。

为了让你的果汁流动起来，解决这个问题的一些方法可能是:(在我看来，其中一些解决方案很糟糕，但我只是把它们放在那里，这样你就可以理解我想要做什么解决)

• AddPerson 不是返回 bool 值，而是返回一个 int(即 0 = 成功，非零等于失败，数字表示失败的原因。

• 在 AddPerson 中，验证失败时抛出自定义异常。每种类型的自定义异常都有其自己的错误消息。此外，每个自定义异常都足够独特，可以在 UI 层中捕获

• 让 AddPerson 返回某种自定义类，该类具有指示验证是否通过或失败的属性，如果失败，原因是什么

• 不确定这是否可以在 VB 或 C# 中完成，但将某种属性附加到 Person 及其基础属性。这个“附加”属性可以包含诸如验证信息之类的内容

• 在此处插入您的想法或模式

• 也许这里还有另一个

对于这个冗长的问题，我深表歉意，但我非常想听听您对此的看法。

谢谢!

Answer 1

多层验证与多层应用程序配合良好。

UI 本身可以进行最简单、最快的检查(是否存在所有必填字段，是否使用适当的字符集等)，以便在用户输入错误时立即提供反馈。

然而，业务逻辑应该承担大部分的验证责任……这一次，如果这是“重复的”，也就是说，如果业务层重新检查一些应该已经在验证中检查过的东西，那么这一次就不是问题了。 UI——BL应该检查所有的业务规则(这会双重检查UI的正确性，启用多个不同的UI客户端，这些客户端在检查中可能并不完美——例如智能手机上的特殊客户端可能没有良好的javascript，等等——还有一点，防范恶意黑客攻击的客户端)。

当业务逻辑将“经过验证的”数据保存到数据库时，该层应该执行自己的检查 - 数据库擅长这一点，而且，同样，不必担心一些重复-- 强制数据完整性是数据库的工作(有一天您可能需要不同的方式向其提供数据，例如，使用“批量加载器”从另一个源导入多个人员，并且确保所有这些方式加载数据始终遵守数据完整性规则)；某些规则(例如唯一性和引用完整性)实际上最好在数据库中强制执行，特别是出于性能原因。

当数据库向业务层返回错误消息(未插入数据，因为约束 X 将被违反)时，后者的工作是用业务术语重新解释该错误，并将结果提供给 UI 以通知用户；当然，BL 也必须类似地向 UI 提供清晰完整的违反业务规则的信息，再次显示给用户。

因此，“自定义对象”显然是“唯一的出路”(例如，在某些情况下，我只是将其设为 JSON 对象)。当数据库拒绝持久化时，保留 Person 对象(以维持其“验证问题”属性)看起来并不是一种尖锐而简单的技术，所以我不太看重这个选项；但如果您需要它(例如，启用“再次告诉我出了什么问题”功能，也许客户端在响应准备好之前离开并且需要稍后顺利重新启动；或者，此类对象的列表以供以后审核等) ，那么“自定义验证失败对象”也可以附加到该列表中...但这是一个“次要问题”，主要是 BL 用这样的方式响应 UI对象(如果插入确实成功，它也可用于提供有用的非错误信息)。