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

Would this be considered duplication of validation logic?

我有这样的样品class

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

在将客户添加到数据库之前,所有这些字段都是必需的。因此,在 service/business 逻辑层中,我对这 4 个属性进行了验证。我验证 FirstName 和 LastName 不为空并且 ContactNumber 大于 0 并且 DateOfBirth 大于 1930(仅作为示例)。在将客户对象传递到 service/business 逻辑层以验证并添加到数据库之前,在 aspx 页面中,我对 ContactNumber 和 DateOfBirth 进行了类型检查。我使用简单的函数,如 IsNumeric 和 IsDate。

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

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

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

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

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

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

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

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

但是,您也是对的,出于以下几个原因,通常在表示层中进行一些验证:它是与用户交互并显示验证错误的地方。此外,一些验证技术只能在表示层中完成,例如 JavaScript,它用于使验证响应更快,而无需每次都访问服务器。但是,JavaScript 验证只是用来增强用户体验,而不是依赖它作为真正的验证,因为它很容易被绕过。

所以从设计的角度来看,您在 service/business 层和表示层的验证被认为是一个很好的设计,而不是糟糕的重复工作。

然而,实践有时并不完全遵循理论。例如,某些验证执行两次可能会非常耗时且成本高昂。在这种情况下,也许您唯一想要放置此类验证的地方就是 service/business 层。