这会被认为是验证逻辑的重复吗？

Question

我有这样的示例类

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int ContactNumber { get; set; }
    public System.DateTime DateOfBirth { get; set; }
}

在将客户添加到数据库之前，所有这些字段都是必需的。所以在服务/业务逻辑层我对这 4 个属性进行验证。我验证 FirstName 和 LastName 不为空且 ContactNumber 大于 0 且 DateOfBirth 大于 1930（仅作为示例）。在我可以将客户对象传递给服务/业务逻辑层以验证并添加到数据库之前，在 aspx 页面中，我对 ContactNumber 和 DateOfBirth 进行类型检查。我使用像 IsNumeric 和 IsDate 这样的简单函数。

我知道验证应该在服务层完成，这样如果将来另一个应用程序需要使用这个逻辑，就可以避免重复。

在 aspx 页面中进行类型检查然后将对象传递给执行所有其他验证的服务层是否常见？我知道避免这种情况的一种方法是使用 javascript。为了争论（从未真正发生过），客户关闭了他的javascript。我正在考虑的另一个选项是将客户添加到数据库的函数接受其所有参数作为对象。这种方式可以避免在 aspx 页面中进行类型检查，而只需在服务层中完成。但是，如果我有 20 个属性作为方法参数发送呢？

Answer 1

这完全取决于您的设计和需求。你提到的点都是有效的点。是的，理想情况下，您需要在服务/业务层进行验证，以防多个表示层调用它，而且因为服务/业务层是负责业务逻辑的层。

但是，您也说得对，通常在表示层中进行一些验证有几个原因：它与用户交互并显示验证错误。此外，一些验证技术只能在表示层中完成，例如 JavaScript，它用于使验证更具响应性，而无需每次都访问服务器。然而，JavaScript 验证仅用于增强用户体验，而绝不能将其作为真正的验证，因为它很容易绕过它。

所以从设计的角度来看，你在服务/业务层和表示层的验证被认为是一个好的设计，而不是重复的努力。

但是，实践有时并不完全遵循理论。例如，某些验证可能非常耗时且执行两次的成本很高。在这种情况下，您希望进行此类验证的唯一位置可能是服务/业务层。

Answer 2

您应该在客户端和服务器上都进行验证。

JavaScript 验证将在客户端执行，如果用户只是犯了一个错误并忘记输入他们的详细信息，它将减少到服务器的往返次数。这也将提供更好的用户体验。

服务器端验证至关重要，也应该执行。如果用户曾经禁用 JavaScript 或攻击者向您的服务器发送恶意表单值，则此验证将启动。由于您使用的是 WebForms，您可以使用框架内的验证控件，例如：RegularExpressionValidator 并具有验证总结。

如果您想自己进行验证，那么这个逻辑最好放在您描述的 ValidationService 中，它可以接受 Customer 类作为参数，而不是您在问题中陈述的 20 个属性。

您可能还想考虑使用其他库来防止 XSS 等攻击。