在开发我的接口（合同）和它们的具体实现时，包括数据模型和存储库，我发现自己质疑验证逻辑应该去哪里。我的一部分（倾向于胜出）说类本身应该负责它自己的验证（字符串最大长度，日期缓冲区等），但我的另一部分说这应该移出到存储库，因为取决于在持久存储上，这些值可能会根据您的存储库实现而改变。
我认为必须在类级别进行一些验证，并且认为它可能应该保持在一起并且即使存储库这样做也不会更改，这就是为什么我倾向于将其保留在类中。
我只想进行 UI 验证，但这还远远不够，因为可以绕过大部分 UI 验证。
好奇人们的想法及其背后的原因。
验证逻辑应该在哪里实现？
到处。
看起来工作量很大，或者额外的开销，但现实是有充分的理由重新验证链上的所有内容，其中最不重要的是在它们成为问题之前捕获错误。
-亚当
验证规则应该在类级别以抽象方式定义，这两者都可以 1) 在类的本地环境中运行 2) 根据需要呈现为其他相关环境的规则，例如 UI 脚本或存储库过程。
这使您可以将逻辑集中在应该在的位置，在类中，并在 UI 和其他任何地方进行辅助验证 - 易于维护，因为它是从类派生的，而不是生活在断开连接的位置的分离逻辑。全能取胜。
我已经取得了很大的成功，将我的所有验证都放在了数据将保存在业务层中的位置附近。例如在属性设置器中。这保证了您只在业务层内传递有效数据，并保证 UI 将从业务层接收有效数据。
如果您的代码总是通过您的业务层，这在某种程度上也避免了在数据层中进行大量验证的需要。
我会教条主义的唯一规则是永远不要信任 UI 级别的验证，因为这一层是最容易被破坏的（尤其是在 Web 应用程序中）。UI 级别验证是一种甜味剂，只是为了让您的用户体验更友好。
两方之间的合同（接口）说，A 和 B 使得双方都有一定的义务。合同是怎么说的？B 应该接收经过验证的数据吗？如果是这种情况，B 不应该实施验证。但是如果 A 是 UI 呢？显然你不想把验证放在那里。通常，最好引入第三方，比如 C。A 与 C 有合同，而 C 又与 B 有合同。B 需要经过验证的数据。A 可能会发送废话。C 执行验证。
如果合同设计得很好，这几乎不会成为问题。修改合同并为每一方承担义务。如果某一方的义务过多，则引入第三方。
当然，在 Web 环境中，您放置在客户端进行验证的任何内容都可以被绕过。
通常我会在课堂上进行验证。然后让设置器引发或抛出异常，或者如果您更喜欢使用返回值。我在 .Net 世界中使用异常，因为我可以将一组自定义异常与明确的验证规则消息返回给消费者/客户端。
验证应该是对象的一部分。将环境作为对象构造函数的参数的一部分。这样，您可以自定义环境的验证逻辑，但对象不必弄清楚它在哪里运行。
我总是使用 UI 验证，即使它充其量是很弱的安全性。它节省了到服务器的往返行程（确实增加了带宽），并且它允许您对错误消息更加用户友好。但它绝不应该是唯一的验证层。