是否将其视为验证逻辑的重复？

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; }
}

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

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

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

Answer 1

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

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

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

如果您想自己进行验证，则此逻辑最好放在您描述的ValidationService中，该方法可以接受Customer类作为参数，而不是问题中所述的20个属性。

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

Answer 2

实际上，这完全取决于您的设计和需求。 您提到的分数都是有效分数。 是的，理想情况下，您需要在服务/业务层中进行验证，以防调用多个表示层，还因为服务/业务层是负责业务逻辑的那一层。

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

因此，从设计的角度来看，您在服务/业务层和表示层的验证被认为是一个好的设计，而不是重复的工作。

但是，实践有时并不完全遵循理论。 例如，某些验证执行两次可能会很长且很昂贵。 在这种情况下，您唯一想进行这种验证的地方就是服务/业务层。