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

Question

在开发我的接口（契约）及其具体实现时，无论是数据模型还是存储库，我发现自己都在质疑验证逻辑应该去哪里。我的一部分（往往会胜出）说类本身应该负责它自己的验证（字符串最大长度，日期缓冲区等），但我的另一部分说这应该移到存储库，因为依赖在持久性存储上，这些值可以根据您的存储库实现进行更改。

我认为必须在类级别进行一些验证，并认为它应该保持在一起，即使存储库也没有改变，这就是为什么我倾向于将它保留在类中。

我完全是在进行UI验证，但这远远不够，因为可以绕过大部分UI验证。

好奇人们的想法及其背后的推理。

Answer 1

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

随处可见。

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

这可能看起来像很多工作或额外的开销，但实际情况是有充分的理由重新验证链中的所有内容，其中最少的是在它们成为问题之前捕获错误。

- 亚当

Answer 2

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

这使得逻辑集中在应有的位置，在类中，以及UI中的辅助验证以及其他任何地方 - 易于维护，因为它来自类而不是生成在断开连接位置的分离逻辑。全能赢。

Answer 3

我已经取得了很大的成功，将我的所有验证都放在了数据将在业务层中保存的地方。例如。在物业安置者。这可以保证您只传递业务层中的有效数据，并保证UI将从业务层接收有效数据。

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

我唯一的教条是从不信任UI级别验证，因为这个层最容易受到攻击（特别是在Web应用程序中）。 UI级别验证是一种甜味剂，只是为了让您的用户体验更加友好。

Answer 4

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

如果合同设计得很好，这几乎不是问题。修改合同并对各方承担义务。如果某一方有太多义务，那么就引入第三方。

Answer 5

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

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

Answer 6

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

我总是使用UI验证，即使它最好是弱安全性。它可以节省到服务器的往返次数（带宽确实加起来），并且它允许您使用错误消息更加用户友好。但它永远不应该是唯一的验证层。