验证逻辑应该在哪里实现？答案

【问题标题】：Where should validation logic be implemented?验证逻辑应该在哪里实现？
【发布时间】：2009-03-26 03:55:44
【问题描述】：

在开发我的接口（合同）和它们的具体实现时，包括数据模型和存储库，我发现自己在质疑验证逻辑应该去哪里。我的一部分（倾向于胜出）说类本身应该负责它自己的验证（字符串最大长度，日期缓冲区等），但我的另一部分说这应该移出到存储库，因为取决于在持久存储中，这些值可能会根据您的存储库实现而改变。

我认为必须在类级别完成一些验证，并且认为它可能应该保持在一起并且即使存储库进行更改也不要更改，这就是我倾向于将其保留在类中的原因。

我只想进行 UI 验证，但这永远不够，因为可以绕过大部分 UI 验证。

好奇人们的想法及其背后的原因。

【问题讨论】：

标签： validation oop standards

【解决方案1】：

验证逻辑应该在哪里实现？

无处不在。

您应该在 UI 级别进行验证，以便用户获得即时、有用的反馈（即，填写一个网络表单，然后在其旁边显示 javascript，“密码太短”，这样您就不会不必要地访问服务器）
您应该验证从用户界面到主软件的任何输入。永远不要相信用户界面，尤其是在大型项目或网站上 - 它们可能会被绕过，或者它们可能由不同的团队开发。
您应该验证函数/方法/类的输入。这些具有与项目要求无关的固有限制（除了能够管理所需输入的范围）。这里的想法是鼓励安全的代码重用。参加一个课程，你知道如果你超出它的参数，它会失败 - 如果它这样做了，它会告诉你。
还有许多其他领域需要进行验证（数据库、备份/恢复、辅助通信渠道等）

这可能看起来工作量很大，或额外开销，但实际上有充分的理由重新验证链中的所有内容，其中最不重要的是在错误成为问题之前发现它们。

-亚当

【讨论】：

这是在回答验证逻辑应该在何时而不是在哪里实现的问题。

【解决方案2】：

验证规则应该在类级别以抽象方式定义，这两者都可以 1) 在类的本地环境中运行 2) 根据需要呈现为其他依赖环境的规则，例如 UI 脚本或存储库过程。

这使您可以将逻辑集中在应位于的位置、类中，并在 UI 和其他任何位置进行辅助验证——易于维护，因为它是从类派生的，而不是生活在断开位置的分离逻辑。全面获胜。

【讨论】：

无，如果它应该从数据库中派生。如果一个人要驾驶另一个人，反之亦然。不要从您的数据库模式中指定用户行为。此外，您不希望您的类单元测试依赖于数据库连接和工件。

【解决方案3】：

我已经取得了很大的成功，我将我的所有验证都放在了数据将保存在业务层中的位置附近。例如。在属性设置器中。这保证了您只在业务层内传递有效数据，并保证 UI 将从业务层接收有效数据。

如果您的代码始终通过您的业务层，这在某种程度上也避免了在数据层中进行大量验证的需要。

我会教条的唯一规则是从不信任 UI 级别的验证，因为这一层最容易被破坏（尤其是在 Web 应用程序中）。 UI 级别验证只是让您的用户体验更友好的甜味剂。

【讨论】：

【解决方案4】：

两方之间的合同（接口）说，A 和 B 双方都有一定的义务。合同是怎么说的？ B 应该接收经过验证的数据吗？如果是这种情况，B 不应该实施验证。但是如果 A 是 UI 呢？显然你不想把验证放在那里。通常，最好引入第三方，例如 C。A 与 C 有合同，而 C 又与 B 有合同。B 需要经过验证的数据。 A 可能会发送废话。 C 执行验证。

如果合同设计得当，这几乎不会成为问题。修改合同并为每一方承担义务。如果某一方的义务太多，那就引入第三方。

【讨论】：

【解决方案5】：

当然，在 Web 环境中，您放置在客户端进行验证的任何内容都可以被绕过。

通常我会在课堂上进行验证。然后让设置器引发或抛出异常，或者如果您更喜欢使用返回值。我在 .Net 世界中使用异常，因为我可以将一组自定义异常与明确的验证规则消息返回给消费者/客户端。

【讨论】：

【解决方案6】：

验证应该是对象的一部分。将环境作为对象构造函数的参数的一部分。这样，您可以自定义环境的验证逻辑，但对象不必弄清楚它在哪里运行。

我总是使用 UI 验证，即使它充其量只是很弱的安全性。它节省了到服务器的往返行程（带宽确实增加了），并且它允许您对错误消息更加用户友好。但它绝不应该是唯一的验证层。

【讨论】：