我有这样的样本课
$con = mysqli_connect($hostname, $username, $password, $database) or die ("Connecting to MySQL failed");
在将客户添加到数据库之前，所有这些字段都是必需的。因此，在服务/业务逻辑层中，我对这4个属性进行了验证。我验证FirstName和LastName不为空，ContactNumber大于0且DateOfBirth大于1930（仅作为示例）。在我可以将客户对象传递给服务/业务逻辑层以验证并添加到数据库之前的aspx页面中，我确实键入了ContactNumber和DateOfBirth的检查。我使用像IsNumeric和IsDate这样的简单函数。
我知道验证应该在服务层完成，这样如果另一个应用程序需要在将来使用这个逻辑，可以避免重复。
在aspx页面中进行类型检查然后将对象传递给执行所有其他验证的服务层是否常见？我知道避免这种情况的一种方法是使用javascript。为了争论（从未真正发生），客户关闭了他的javascript。我想到的另一个选项是将客户添加到数据库的函数将其所有参数作为对象接受。这样可以在aspx页面中避免类型检查，只需在服务层中完成。但是，如果有20个属性我作为方法参数发送了怎么办？
答案 0 :(得分：1)
您应该在客户端和服务器上进行验证。
JavaScript验证将在客户端执行，并且如果用户只是犯了错误而忘记输入他们的详细信息，则会减少到服务器的往返次数。这也可以提供更好的用户体验。
服务器端验证至关重要，也应该执行。如果用户曾禁用JavaScript或攻击者向您的服务器发送恶意表单值，则此验证将启动。由于您使用WebForms，您可以使用框架内的验证控件，例如：RegularExpressionValidator并有一个验证摘要。
如果您想自己进行验证，那么这个逻辑最好位于您描述的ValidationService中，它可以接受Customer类作为参数，而不是您在问题中声明的20个属性。
您可能还想考虑使用其他库来防止XSS等攻击。
答案 1 :(得分：1)
这完全取决于您的设计和需求。你提到的要点都是有效的。是的，理想情况下，您需要在服务/业务层中进行验证，以防多个表示层调用它，还因为服务/业务层是负责业务逻辑的层。
但是，您也是正确的，通常在表示层中进行一些验证有以下几个原因：它与用户交互并显示验证错误。此外，一些验证技术只能在表示层中完成，例如JavaScript，用于使验证响应更快，而不需要每次都去服务器。但是，JavaScript验证仅用于增强用户体验，但从不依赖它作为真正的验证，因为它很容易绕过它。
因此，从设计的角度来看，您在服务/业务层和表示层中的验证被认为是一个很好的设计，而且不是重复工作。
然而，练习有时并不完全遵循理论。例如，执行两次验证可能非常长且昂贵。在这种情况下，您可能唯一想要进行此类验证的地方是服务/业务层。