您在哪里进行验证？

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

您的应用程序分为三层，

• 前端UI层，可以是asp.net webform，或者window（用于编辑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 返回的布尔值不足以让我在 UI 层向用户提供保存过程失败的明确原因。那么孤独的开发者该怎么办呢？最终，我希望 AddPerson 方法能够确保其要保存的内容有效，如果不是，则能够向我的 UI 层传达其无效的原因。

为了让你的果汁流动起来，解决这个问题的一些方法可能是：（在我看来，其中一些解决方案很糟糕，但我只是把它们放在那里，以便你了解我正在尝试解决的问题）

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

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

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

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

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

• 也许这里还有另一个

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

Thanks!

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

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

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

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

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

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